Back out v1.49. Recent findings suggest sparc64 may not be ready for

-O2 on kernel compiles after all.  While working on adding a KASSERT
to sparc64/sparc64/rwindow.c I found that it was "position sensitive",
putting it above a call to flushw() instead of below caused corruption
of processes on the system.  jake and jhb have both confirmed there is
no obvious explanation for that.  The exact same kernel code does not
have the process corruption problem if compiled with -O instead of -O2.
There have been signs of similar issues floated on the sparc64@ mailing
list, lets see if this helps make them go away.

Note this isn't an optimal fix as far as the file format goes, if this
disgusts too many people I'll fix it the right way.  Since compiling
with something other than -O is a known problem this format would prevent
a change to the default causing grief.  And this may also help motivate
finding out what the compiler is doing wrong so we can shift back to
using -O2. :-)

My turn for the pointy hat...  One of the florescent ones...

MFC after:	2 days

1 files changed, 1 insertions, 1 deletions

diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index 07b4a9d..86bbb62 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -24,7 +24,7 @@ COPTFLAGS?=-O2 -frename-registers -pipe
 . elif ${MACHINE_ARCH} == "ia64"
 COPTFLAGS?=-O2 -pipe
 . elif ${MACHINE_ARCH} == "sparc64"
-COPTFLAGS?=-O2 -pipe
+COPTFLAGS?=-O -pipe
 . elif ${MACHINE_ARCH} == "arm"
 COPTFLAGS?=-O2 -pipe
 . else