[Bug c/27152] New: gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
Ok, I have been trying to track this bug down for weeks and spent quite a lot
of time on it. I am now pretty much sure that this is a bug within gcc even
though it's quite hard to prove. So before I sum it up again here, first two
links to my original bug reports over at the Gentoo and Xorg bugzilla:
https://bugs.gentoo.org/show_bug.cgi?id=127608
https://bugs.freedesktop.org/show_bug.cgi?id=6533
When the Xorg server package is being compiled with anything above -O0, only
the first switch to the VT works. Every other switch results in a black screen,
even though I am able to enter commands blindly. After Xorg has been stopped,
sometimes the VT is being restored, even though some VTs are left in a garbled
state like some kind of video memory corruption occured.
The most interesting part is: this only happens with gcc 4.1 and above. If I
compile the Xorg server with gcc 3.4.5 or 4.0.3, everything works just fine. I
have tried 4.1.1 and 4.2 snapshots a few days ago but the problem remained.
What's also note worthy: just replacing the Xorg binary with for example an -O0
compiled one, fixes the problem too. So no matter what wrong code is being
produced, it's in Xorg server binary.
I have tried to nail the bug down with to some specific CFLAG but I had no
luck. Tried the following so far one by one:
-march=athlon64 -mtune=athlon64 -O1 -pipe
-fno-defer-pop -fno-delayed-branch -fno-guess-branch-probability
-fno-cprop-registers -fno-loop-optimize -fno-if-conversion -fno-if-conversion2
-fno-tree-ccp
-fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-ter
-fno-tree-lrs -fno-tree-sra
-fno-tree-copyrename -fno-tree-fre -fno-tree-ch -fno-merge-constants
-fno-tree-loop-optimize -fno-omit-frame-pointer -fno-tree-sink
-fno-tree-copy-prop
-fno-tree-vect-loop-version -fno-tree-salias
-fno-default-inline -fno-inline -fno-early-inlining
-fno-peephole -fno-peephole2 -fno-move-loop-invariants
-fno-ivopts -fno-schedule-insns -fno-strength-reduce
-fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops
I also tried to debug the problem with gdb but I it's more like looking for the
needle in the haystack if you don't know what you are looking for.
My system is a pure 64bit Gentoo system, everything compiled with gcc 4.1.0 and
just -march=athlon64 -mtune=athlon64 -O2 -pipe -ftracer -fweb
-frename-registers as CFLAGS. Running glibc 2.4 and kernel 2.6.16.
If you need any more detailed informations, help or alike, I will gladly help.
It's just that I am currently stuck and don't know what else I could try to
find the needle.
--
Summary: gcc 4.1.x/4.2 produces wrong code for Xorg server
(1.0.2, modular)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ua_bugz_gcc at mortal-soul dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #3 from ua_bugz_gcc at mortal-soul dot de 2006-04-14 11:02 --- First of all, thanks for the tip! :) Even though this took me all morning I have been able to identify where things go wrong. It's lnx_KbdMap.c in the xorg-server tree: hw/xfree86/os-support/linux. If I compile just this with -O0, everything works just fine. The -fwrapv makes no difference by the way. I tried to split things up and figured that it has to be something with the arrays and readKernelMapping() in there. If I take out the KbdGetMapping() and put it into its own file, it depends on how readKernelMapping() and its stuff are being compiled (-O0 or >-O0) if things work or not. There are no compiler warnings with this file either. I hope nobody minds if I attach the object files and the source file to this bug report. I tried to understand the disassembled readKernelMapping() but it has been ages since I last touched anything assembler, so I guess there are more qualified persons around who could do a lot better than I do. :-) BTW, I had to use -fno-inline-functions-called-once otherwise readKernelMapping() would have been inlined. For the problem itself, this makes no difference, it just makes things harder to debug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #4 from ua_bugz_gcc at mortal-soul dot de 2006-04-14 11:04 --- Created an attachment (id=11270) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11270&action=view) lnx_KbdMap.c from xorg-server/hw/xfree86/os-support/linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #5 from ua_bugz_gcc at mortal-soul dot de 2006-04-14 11:05 --- Created an attachment (id=11271) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11271&action=view) lnx_KbdMap.o with wrong code (-O2 compiled) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #6 from ua_bugz_gcc at mortal-soul dot de 2006-04-14 11:05 --- Created an attachment (id=11272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11272&action=view) working lnx_KbdMap.o (-O0 compiled) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #7 from ua_bugz_gcc at mortal-soul dot de 2006-04-14 18:12 --- One more note: just figured that -O2 works fine if -fno-unit-at-a-time is supplied too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
[Bug middle-end/27152] gcc 4.1.x/4.2 produces wrong code for Xorg server (1.0.2, modular)
--- Comment #8 from ua_bugz_gcc at mortal-soul dot de 2006-04-15 14:44 --- Sorry guys for all the fuss. I spent weeks on this and now it officially turns out a Xorg bug. (https://bugs.freedesktop.org/show_bug.cgi?id=6472) Xorg is writing out of bounds on an array. So with gcc optimizations turned on, I guess gcc reorders data and important things are overwritten. No watter what, please mark invalid. Sorry again but everything pointed to gcc... :-(( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27152
