User account creation filtered due to spam.

Bug 21564 - [4.1 Regression] Fatal miscompile with -O1 -finline-functions
Summary: [4.1 Regression] Fatal miscompile with -O1 -finline-functions
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.0
: P1 critical
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, wrong-code
Depends on:
Blocks:
 
Reported: 2005-05-14 00:45 UTC by Martin Drab
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
This is the testcode that triggers the bug (stripped from latest CVS LAME). (4.71 KB, text/plain)
2005-05-14 00:46 UTC, Martin Drab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Drab 2005-05-14 00:45:00 UTC
Hi,

during compilation of LAME I found out that the following gcc

--------------------------
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050512/gcc-CVS-20050512/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc
--libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec
--sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1
--with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib
--disable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs
--enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage
--disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath
--enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization
--with-system-zlib --with-libbanshee --with-demangler-in-ld
--with-arch=athlon-xp --disable-libada --enable-languages=c,c++,f95,objc
Thread model: posix
gcc version 4.1.0 20050512 (experimental)
--------------------------

miscompiles the code when compiled with (at least) following flags:

--------------------------
gcc -O1 -fno-strict-aliasing -finline-functions -o lame lame.c
--------------------------

But when compiling with only the following:

--------------------------
gcc -O1 -fno-strict-aliasing -finline-functions -o lame lame.c
--------------------------

it works OK. I extracted as small part of it as possible, so that you can test
it, but still it is too big to just list here (cca 17KB), so I'll send it as an
attachment after commiting this bugreport template (because there is no way to
do in directly from here, before the bug is created :().

The miscompilation occurs on line 302 of the attached file. It looks something
like this:

--------------------------
if (gfp->out_samplerate == 0)
         gfp->out_samplerate = optimum_samplefreq( (int)gfp->lowpassfreq,
gfp->in_samplerate); /* <----- Here's the problem! */
--------------------------

The problem is that though before this 'gfp->out_samplerate' IS zero,
the value of 'gfp->out_samplerate' keeps its previous value (which is 0 in this
case) while it should have obtained a new value from calling the
'optimum_samplefreq( (int)gfp->lowpassfreq, gfp->in_samplerate)', which should
return (and returns) a value of 8000 in this case. I tried to strip the
surrounding code a bit more, but it seems not to trigger the bug then. When you
compile and run it, it may SEGFAULT afterwards (after the bugged part), because
I didn't put there some necessary initializations and some other things in order
to make the example as small as possible. But that is OK and should be of no
concern. When you compile the whole LAME application (library), everything is
running without SEGFAULTs and the bug is still there.

I consider this a fatal bug, since it doesn't reveal itself during compilation.
Everything compiled just fine. Except for that it didn't work as expected then.

I hope there is nothing wrong with the test code. But even if it is, gcc
certainly shouldn't miscompile like this.
Comment 1 Martin Drab 2005-05-14 00:46:45 UTC
Created attachment 8887 [details]
This is the testcode that triggers the bug (stripped from latest CVS LAME).
Comment 2 Martin Drab 2005-05-14 00:49:17 UTC
(In reply to comment #0)

> 
> But when compiling with only the following:
> 
> --------------------------
> gcc -O1 -fno-strict-aliasing -finline-functions -o lame lame.c
> --------------------------

Sorry this should have been:

--------------------------
gcc -O0 -fno-strict-aliasing -finline-functions -o lame lame.c
--------------------------
Comment 3 Andrew Pinski 2005-05-14 01:09:14 UTC
I have no idea what is causing the problem.  I tried the following options and it is still messed up:
" -O1 -finline-functions -fno-tree-dominator-opts -fno-tree-fre -fno-tree-ccp -fno-tree-store-ccp 
-fno-tree-salias -fno-tree-sink -fno-tree-dse -fno-tree-sra "
Comment 4 Andrew Pinski 2005-05-14 01:10:30 UTC
some how the store is becoming dead.
Comment 5 Andrew Pinski 2005-05-14 01:19:04 UTC
This is an aliasing issue, -O1 -fno-ivopts -finline-functions works.
DCE thinks the store to gfp->out_samplerate is dead.

Note the code will seg fault right away anyways, you need the following change to main:
Replace:
    lame_global_flags *gf ;
With:
    lame_global_flags gf1;
    lame_global_flags *gf = &gf1;
Comment 6 Andrew Pinski 2005-05-14 01:20:47 UTC
Strict aliasing does not matter in this case as it is not enabled at -O1 anyways.
Comment 7 Andrew Pinski 2005-05-14 01:46:09 UTC
Oh and -fno-tree-saliasing does not fix it, this is just for Dan.
Comment 8 Andrew Pinski 2005-05-14 01:46:56 UTC
(In reply to comment #7)
> Oh and -fno-tree-saliasing does not fix it, this is just for Dan.
I mean "-fno-tree-salias".
Comment 9 Martin Drab 2005-05-14 01:56:01 UTC
(In reply to comment #5)
> This is an aliasing issue, -O1 -fno-ivopts -finline-functions works.
> DCE thinks the store to gfp->out_samplerate is dead.
> 
> Note the code will seg fault right away anyways, you need the following change
to main:
> Replace:
>     lame_global_flags *gf ;
> With:
>     lame_global_flags gf1;
>     lame_global_flags *gf = &gf1;


Yes, you are absolutely correct. Just a result of too much stripping and 3:00
AM. ;-) But the problem isn't affected by that.
Comment 10 Martin Drab 2005-05-14 02:01:37 UTC
(In reply to comment #6)
> Strict aliasing does not matter in this case as it is not enabled at -O1 anyways.

It does! Although not with -O1. But I just wanted to point out (which I forgot
before) that with '-fstrict-aliasing' it works, i.e.:

----------------------
gcc -O1 -fstrict-aliasing -finline-functions -I. -o lame lame.c
----------------------
Comment 11 Martin Drab 2005-06-13 23:42:26 UTC
I don't know who did it and how, but recently I checked latest CVS after a while
(CVS-20050612) and all of a sudden it seems to work. The bug seems to be gone.
Can anyone check it out and confirm? Any idea what happend?
Comment 12 Martin Drab 2005-06-13 23:45:12 UTC
(In reply to comment #11)
> I don't know who did it and how, but recently I checked latest CVS after a while
> (CVS-20050612) and all of a sudden it seems to work. The bug seems to be gone.
> Can anyone check it out and confirm? Any idea what happend?

Well, actually it was CVS-20050613 that I checked (sorry a misspell). But anyway.
Comment 13 Andrew Pinski 2005-06-30 13:11:02 UTC
Fixed.