Summary: | gcc 4.3.1 incorrect compilation of xorg-server>=1.3.0.0-r6 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Grégoire Favre <gregoire.favre> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christophe, leio, rbu, x11 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Crude workaround for gcc loop optimization bug in xorg-server |
Description
Grégoire Favre
2008-06-15 20:16:05 UTC
This bug still seems to exist in 1.4.99.902 and gcc 4.3.1 (on amd64). It looks a little bit scary, I did some debugging in the xorg server code and it seems that the hash table containing the X resources seems to get corrupted (the ->next pointer for chaining hash entries) and it crashes when resizing the hash table (which is a static method just below AddResource, where the crash is reported in the backtrace). This is independent from the graphics driver and goes away when not compiling with -march=nocona. valgrind doesn't print anything before the failed read attempt. The ->next pointer is just a few bytes above the null pointer before the dereference fails. The hash code itself looks foolproof, so I guess someone is writing over its bounds, possibly either due to a miscompilation or some optimization kicking in with -mnocona that is not expected (like the signed int wrapping assumption problem). I'll dig a bit further. Christophe, did your further digging yield any results? I could also reproduce this bug on 1.4*, i810, core2 and gcc-4.3.1 No, not yet. I will be on "vacation" (*) the next two weeks and this will be one of my projects to tackle. :-) (*) not at work, but not at the beach either Created attachment 162781 [details, diff]
Crude workaround for gcc loop optimization bug in xorg-server
Ok, I have nailed this down. It is a pretty serious compiler screw-up. A pretty simple loop initialising pointers seems to get screwed up by the tree vectorizer (every second entry having the wrong offset). I'll attach an extremely crude workaound (not meant to be applied, it really just masks the ugly compiler bug) if someone wants to know what loop gets screwed up. The workaround moves the loop into its own function which makes it not trigger the problem. Let's see if the problem is serious enough to hold up 4.3.2 even further. ;-) (will try to build a test case and report to gcc bugzilla) Thanks for tracking this down, Christophe! Reassigning to the toolchain team since it's a gcc bug. The bug is fixed upstream: http://gcc.gnu.org/viewcvs?view=rev&revision=139095 I upgraded gcc to 4.3.2 that became available in ~arch today, rebuilt xorg-server with -ftree-vectorize, restarted Xorg and it works fine now when compiled with gcc-4.3.2 and tree vectorizer (as expected, given the fix is included upstream in 4.3.2) (In reply to comment #9) > I upgraded gcc to 4.3.2 that became available in ~arch today, rebuilt > xorg-server with -ftree-vectorize, restarted Xorg and it works fine now when > compiled with gcc-4.3.2 and tree vectorizer (as expected, given the fix is > included upstream in 4.3.2) > Thanks. I'm not going to be backporting all of these fixes, so this is resolved now (by using the newest version) |