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.

-- 
           Summary: Fatal miscompile with -O1 -fno-strict-aliasing -finline-
                    functions
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: drab at kepler dot fjfi dot cvut dot cz
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21564

Reply via email to