http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #5 from Matt Hargett <matt at use dot net> 2011-04-05 03:53:19 UTC --- (In reply to comment #4) > Anyway, please read http://gcc.gnu.org/bugs.html, there is nothing we can do > from the information you've provided. Trying to find from a vague description > of where you see the crash a difference in assembly is very hard, plus it may > very well be just a bug in the sources you are compiling. If -O2 works and > -O3 > doesn't, try to add __attribute__((noinline)) resp. > __attribute__((optimize(2))) > resp. __attribute__((optimize(3))) to various suspect routines in the file to > try to narrow it down to a single problematic routine (perhaps with some > functions inlined into it), which will work fine if the whole file is compiled > with -O3 just that routine is -O2 (and perhaps functions inlined into it) and > will misbehave if everything is compled with -O2 just that function is > compiled > with -O3. Then try to make a self-contained executable testcase out of it > (just call that routine from some other CU's main, perhaps with the minimal > necessary setup for it and stub everything it calls. For (suspected) > miscompilation we really need to be able to reproduce it ourselves, > preferrably > with a minimal testcase, otherwise we can't do anything on it unless you debug > the problem yourself down to pointing a bug somewhere exact in the assembly. I've got a greatly reduced testcase that I'm continuing to pare down. I'll attach the self-contained example tomorrow.