bug-coreutils
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]