Karl Berry writes: > > Hi Alan, > > run gcc -c -save-temps on it, and publish the resulting .i and .s > files for inspection. The conftest programs are already pretty > minimal so it should be easy to determine whether the assembly code > correctly corresponds to the preprocessed C code. > > I'm afraid my x86 assembler knowledge is near-nil, so it's not easy for > me :). Before I try to make this an official gcc bug report, maybe you
I did mean "easy" for the collective mind of the mailing list. > could take a look/ The attached tar file has the .i and the .s both for > -O (which gets a seg fault) and -O2 (which hangs). With no -O option at > all, the binary exits (successfully). The presence or absence of -g > makes no difference. I threw in the .c and .h for the heck of it. It's definitely a compiler problem. That extern inline asm alias trickery failed to work. (Much effort there to optimize a function that according to its own man page "should never be used") It ended up as Andreas Schwab suggested: an infinite tail recursion. -O1 segfaults eventually because the recursion grows the stack to infinite size. -O2 optimized the recursion into a jump, eliminating the stack growth. In the future, .s files are usually better without -g (as long as you're not looking for a bug in the part of the compiler that generates the debugging info). The assembler directives that produce the debugging symbols add a lot of clutter. -- Alan Curry
