| Summary: | [4.1 Regression] Fatal miscompile with -O1 -finline-functions | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Martin Drab <martin.drab> |
| Component: | tree-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | dnovillo, gcc-bugs |
| Priority: | P1 | Keywords: | alias, wrong-code |
| Version: | 4.1.0 | ||
| Target Milestone: | 4.1.0 | ||
| 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). | ||
Created attachment 8887 [details]
This is the testcode that triggers the bug (stripped from latest CVS LAME).
(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 -------------------------- 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 " some how the store is becoming dead. 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;
Strict aliasing does not matter in this case as it is not enabled at -O1 anyways. Oh and -fno-tree-saliasing does not fix it, this is just for Dan. (In reply to comment #7) > Oh and -fno-tree-saliasing does not fix it, this is just for Dan. I mean "-fno-tree-salias". (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. (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 ---------------------- 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? (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. Fixed. |
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.