Re: Likely code generation bug in GCC 4.0.1

Re: Likely code generation bug in GCC 4.0.1

[Andrew Haley]

Claus Fischer writes:
 > 
 > I think I found a code generation bug in GCC 4.0.1.
 > 
 > I'm sending this mail to make sure this bug is known and
 > is or will be removed in newer versions.
 > On a quick glance I couldn't find it in the bug database,
 > so it may not be known.

Redirected to gcc-help.

Please send a full test case that can be run, with full information
about the expected effect.

Thanks,
Andrew.

Re: Likely code generation bug in GCC 4.0.1

[Claus Fischer]

On Mon, May 14, 2007 at 10:18:26AM +0100, Andrew Haley wrote:
: Claus Fischer writes:
:  > 
:  > I think I found a code generation bug in GCC 4.0.1.
:  > 
:  > I'm sending this mail to make sure this bug is known and
:  > is or will be removed in newer versions.
:  > On a quick glance I couldn't find it in the bug database,
:  > so it may not be known.
: 
: Redirected to gcc-help.
: 
: Please send a full test case that can be run, with full information
: about the expected effect.


The full test case is way too big to run and contains data
which I don't have authority to disclose publicly.


I was hoping that someone could take a look at the assembler
code since I'm not proficient in assembly.

I've already spent four hours tracking the bug to this location,
I just can't verify that the assembly conforms with what I deduce
from observable behaviour.

Claus


-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

Re: Likely code generation bug in GCC 4.0.1

[Andrew Haley]

Claus Fischer writes:
 > On Mon, May 14, 2007 at 10:18:26AM +0100, Andrew Haley wrote:
 > : Claus Fischer writes:
 > :  > 
 > :  > I think I found a code generation bug in GCC 4.0.1.
 > :  > 
 > :  > I'm sending this mail to make sure this bug is known and
 > :  > is or will be removed in newer versions.
 > :  > On a quick glance I couldn't find it in the bug database,
 > :  > so it may not be known.
 > : 
 > : Redirected to gcc-help.
 > : 
 > : Please send a full test case that can be run, with full information
 > : about the expected effect.
 > 
 > 
 > The full test case is way too big to run and contains data
 > which I don't have authority to disclose publicly.

I'm not asking for your full code.  If you believe that the bug is in
the code generated for the source you posted, presumably you can
create a test wrapper.

Experience over meny years has shown us that this is the bet way to
find and fix bugs in gcc.  It's much more productive than staring at
thousands of lines of assembly language.

 > I was hoping that someone could take a look at the assembler
 > code since I'm not proficient in assembly.
 > 
 > I've already spent four hours tracking the bug to this location,
 > I just can't verify that the assembly conforms with what I deduce
 > from observable behaviour.

The problem is that gcc reorders and reorganizes code to such an
extent that it can be exceedingly hard to find the equivalent code.

Andrew.

Re: Likely code generation bug in GCC 4.0.1

[Claus Fischer]

On Mon, May 14, 2007 at 10:35:57AM +0100, Andrew Haley wrote:
: Claus Fischer writes:
:  > On Mon, May 14, 2007 at 10:18:26AM +0100, Andrew Haley wrote:
:  > : Claus Fischer writes:
:  > :  > 
:  > :  > I think I found a code generation bug in GCC 4.0.1.
:  > :  > 
:  > :  > I'm sending this mail to make sure this bug is known and
:  > :  > is or will be removed in newer versions.
:  > :  > On a quick glance I couldn't find it in the bug database,
:  > :  > so it may not be known.
:  > : 
:  > : Redirected to gcc-help.
:  > : 
:  > : Please send a full test case that can be run, with full information
:  > : about the expected effect.
:  > 
:  > 
:  > The full test case is way too big to run and contains data
:  > which I don't have authority to disclose publicly.
: 
: I'm not asking for your full code.  If you believe that the bug is in
: the code generated for the source you posted, presumably you can
: create a test wrapper.


I can, but it's likely to take me more than five times as long
as someone who knows assembler to take a (quick) glance. If that
quick glance doesn't get us further, I'm very willing to do my
homework/test case, even though just switching to gcc 4.1 would
probably solve MY problem completely. It's just out of desire to
help gcc people keep gcc bug-free that I have tried to "isolate"
this bug.

I have already spent a lot of time tracking this down, and I feel
I have reached a point where the imbalance of time I'd have to
spend to create a complete test case, and of the time required to
look at the assembly, is grossly in favor of learning assembly
myself :-)

[ Unfortunately, creating the MINGW cross compilation environment
  itself is a task that would probably keep most gcc developers from
  examining the case, even if I posted the instructions. ]

: Experience over meny years has shown us that this is the bet way to
: find and fix bugs in gcc.  It's much more productive than staring at
: thousands of lines of assembly language.

I know and understand. I typically try to do that. But that's easier
for a recent GCC as shipped with Linux, than for a cross-compilation
environment that involves Mingw and an older GCC.

: The problem is that gcc reorders and reorganizes code to such an
: extent that it can be exceedingly hard to find the equivalent code.

I understand that.

Claus

-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

Re: Likely code generation bug in GCC 4.0.1

[Andrew Haley]

Claus Fischer writes:
 > On Mon, May 14, 2007 at 10:35:57AM +0100, Andrew Haley wrote:
 > : Claus Fischer writes:
 > :  > On Mon, May 14, 2007 at 10:18:26AM +0100, Andrew Haley wrote:
 > :  > : Claus Fischer writes:
 > :  > :  > 
 > :  > :  > I think I found a code generation bug in GCC 4.0.1.
 > :  > :  > 
 > :  > :  > I'm sending this mail to make sure this bug is known and
 > :  > :  > is or will be removed in newer versions.
 > :  > :  > On a quick glance I couldn't find it in the bug database,
 > :  > :  > so it may not be known.
 > :  > : 
 > :  > : Redirected to gcc-help.
 > :  > : 
 > :  > : Please send a full test case that can be run, with full information
 > :  > : about the expected effect.
 > :  > 
 > :  > 
 > :  > The full test case is way too big to run and contains data
 > :  > which I don't have authority to disclose publicly.
 >
 > 
 > [ Unfortunately, creating the MINGW cross compilation environment
 >   itself is a task that would probably keep most gcc developers from
 >   examining the case, even if I posted the instructions. ]

Sure, but if we had a test case we'd know if this bug was mingw
specific.

Anyway, something you should know: there is zero probablility that any
bugs in gcc 4.0.x will ever be fixed: the branch was closed after the
release of GCC 4.0.4.

Andrew.

Re: Likely code generation bug in GCC 4.0.1

[Claus Fischer]

On Mon, May 14, 2007 at 10:59:37AM +0100, Andrew Haley wrote:
: Sure, but if we had a test case we'd know if this bug was mingw
: specific.

Right, I don't know that myself now. But I can recompile gcc 4.0.1
for Linux (I have the sources archived) and find that out.

I'll give you notice.

: Anyway, something you should know: there is zero probablility that any
: bugs in gcc 4.0.x will ever be fixed: the branch was closed after the
: release of GCC 4.0.4.

I know that, and if there was any indication that this specific bug
was fixed later, I'd have saved me (and you) the hassle.


Claus


-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/

Re: Likely code generation bug in GCC 4.0.1

[Claus Fischer]

On Mon, May 14, 2007 at 12:15:53PM +0200, Claus Fischer wrote:
: On Mon, May 14, 2007 at 10:59:37AM +0100, Andrew Haley wrote:
: : Sure, but if we had a test case we'd know if this bug was mingw
: : specific.
: 
: Right, I don't know that myself now. But I can recompile gcc 4.0.1
: for Linux (I have the sources archived) and find that out.
: 
: I'll give you notice.

Apparently, the bug also happens on Linux. However, two effects
make it very difficult to isolate it in a small test example:

(1) Linux apparently places variables in slightly different
    places each time the program is started (stack smashing
    protection).
    That can be fixed with
       sysctl -w kernel.randomize_va_space=0

(2) With that out of the way, the runs of the simulator are
    apparently reproducible for the same binary, but not after
    recompilation. Recompiling the code after a slight change
    somewhere else changes the behaviour.

    Now that could indicate usage of an uninitialized variable
    from the stack, only valgrind doesn't report any such.

Anyway, things have gotten too involving for me to spend more
time on this. I have rebuilt my cross-compiler environment with
gcc 4.1.2 and I hope that solves my problems.

Regards,

Claus


-- 
Claus Fischer <claus.fischer@clausfischer.com>
http://www.clausfischer.com/