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?