GCC Bugzilla Bug 15386

MPlayer triggers another compiler bug...

The WMA (Windows Media audio codec) decoder of FFmpeg/libavcodec
(http://ffmpeg.org) wmadec.c gets miscompiled by gcc versions >=3.1 when
compiled with -mcpu=k6 and/or -O1 or above.  When playing a WMA sample with
MPlayer all you get is pop at the beginning and then no sound.  The problem
disappears with either -mcpu=pentium-mmx or -O0 (changing one parameter is
enough to make the problem go away, either one works).

Here is the complete command line and output when compiling the file:

/var/tmp/gcc-3.5-20040502/bin/gcc -I../libvo/ -I../../libvo -I/usr/X11R6/include
-g -O4 -march=k6 -mcpu=k6 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-DHAVE_AV_CONFIG_H -I.. -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE
-Wall -save-temps -c -o wmadec.o wmadec.c && make && cd .. && make
gcc: warning: -pipe ignored because -save-temps specified
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.

I have tried several gcc versions, 2.95.3 and 3.0.4 are OK, 3.1, 3.1.1, 3.2.3,
3.3.2, 3.4.0 and 3.5.0-20040502 all display the problem.

gcc -v output:
Configured with: ../gcc-3.1/configure --prefix=/var/tmp/gcc-3.1/
Thread model: single
gcc version 3.1

I put the file together with all the headers necessary to compile it, the .o and
.i files and a sample to test the broken sound with MPlayer on my homepage:

http://www.mplayerhq.hu/~diego/gcc/

If you require further info or testing I will be more than happy to provide it.

Does adding -fno-strict-aliasing work?

No, -fno-strict-aliasing does not help.

Which version of binutils do you use?

binutils version: 2.14.90.0.7-6

Some more information: My machine is a K6-III 500 running current Debian
unstable with a homebrewed 2.4.25 kernel.

Does lowering the optimization to -O2 help? (Note -O4 is the same as -O3).

No, -O2 does not help.  As noted above the problem goes away with -O0 (-O1
still
has the bug) or -mcpu=pentium-mmx or both.

One of the things that would really help us is if you could split 
up the one file that is miscompiled into a number of files each 
of which has exactly one function, and try to figure out which 
function is miscompiled. One of the reasons why we have trouble 
doing anything with your report except for poking in the dark is 
because it is very hard to figure out what exactly goes wrong in 
applications that we don't know, and we usually need quite some help 
from application developers to figure out where the bug is. So if 
you could try to cut the problem down to one or a few functions, it 
would be a tremendous help. The next step is to determine for which 
arguments this function does the wrong thing, and to put together 
a small testcase where this one function is called with just these 
parameters for which the output is known. 
 
Thanks 
  Wolfgang 

We need a preprocessed testcase to start working on it.

small remark: Adding -fno-inline to the compilation flags does not help.

I managed to split the file in two and isolate the bug to a small part of the
original file that only contains two functions, a large and a small one.

void wma_lsp_to_curve_init(WMADecodeContext *s, int frame_len)
int wma_decode_init(AVCodecContext * avctx)

All relevant files and the output of gcc can be found at

http://www.mplayerhq.hu/~diego/gcc/

I hope this satisfies your requirements, if there is anything else I can do,
please let me know.

Does -ffloat-store help at all?

-ffloat-store fixes the problem.

This is a dup of bug 323, the problem is with excessive precession.

*** This bug has been marked as a duplicate of 323 ***

Hmmm, how can a bug that started appearing with 3.1 be duped against a bug open
against 2.95.2 when 2.95.3 has no problems at all?