[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: btwowc(EOF) hang with gcc 4.4.2
From: |
Alan Curry |
Subject: |
Re: btwowc(EOF) hang with gcc 4.4.2 |
Date: |
Thu, 17 Dec 2009 20:12:24 -0500 (GMT+5) |
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