4.2 misscompiles libavcodec/h264.o from FFmpeg project. The likely cause of this problem is lies in the file cabac.h (in attachment) gcc-4.0 and 4.1.0 compile this file correctly. Here's the commandline: /home/guillaume/Prgm/gcc/bin/gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I.. -I.. -I../libavutil -Wdeclaration-after-statement -fno-PIC -O4 -march=pentium-m -mtune=pentium-m -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include -I/usr/include/SDL -D_REENTRANT -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/include/dvdnav -I/usr/include/freetype2 -c -o h264.o h264.c -v -save-temps gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20061007/configure --prefix=/home/guillaume/Prgm/gcc/ Thread model: posix gcc version 4.2.0 20061007 (experimental) /home/guillaume/Prgm/gcc/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -E -quiet -v -I.. -I.. -I../libavutil -I/usr/include -I/usr/include/SDL -I/usr/include/kde/artsc -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/include/dvdnav -I/usr/include/freetype2 -iprefix /home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/ -D_REENTRANT -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_REENTRANT h264.c -march=pentium-m -mtune=pentium-m -Wdeclaration-after-statement -fno-PIC -ffast-math -fomit-frame-pointer -O4 -fpch-preprocess -o h264.i ignoring nonexistent directory "/home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "/home/guillaume/Prgm/gcc//lib/gcc/i686-pc-linux-gnu/4.2.0/include" ignoring nonexistent directory "/home/guillaume/Prgm/gcc//lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory ".." ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory ignoring duplicate directory "/usr/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: .. ../libavutil /usr/include/SDL /usr/include/kde/artsc /usr/include/glib-2.0 /usr/lib/glib-2.0/include /usr/include/dvdnav /usr/include/freetype2 /home/guillaume/Prgm/gcc/bin/../lib/gcc/i686-pc-linux-gnu/4.2.0/include /usr/local/include /home/guillaume/Prgm/gcc//include /usr/include End of search list. /home/guillaume/Prgm/gcc/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -fpreprocessed h264.i -quiet -dumpbase h264.c -march=pentium-m -mtune=pentium-m -auxbase-strip h264.o -O4 -Wdeclaration-after-statement -version -fno-PIC -ffast-math -fomit-frame-pointer -o h264.s GNU C version 4.2.0 20061007 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20061007 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 9d78c482f3158f545a4217a7c698d3a2 h264.c: In function 'decode_cabac_residual': h264.c:6120: warning: initialization from incompatible pointer type as -V -Qy -o h264.o h264.s GNU assembler version 2.16.91 (i486-linux-gnu) using BFD version 2.16.91 20060118 Debian GNU/Linux
Created attachment 12418 [details] the offending file (results in a grey picture)
Created attachment 12419 [details] The header that seems to hold the code that's misscompiled
Does it work when compiled with -O0 instead of -O4? How about -O1? Besies above, I noticed that the asm in get_cabac looks to be clobbering memory but is not marked as such.
(In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? > > Besies above, I noticed that the asm in get_cabac looks to be clobbering memory > but is not marked as such. > Andrew, this testcase violates aliasing rules. h264.c: In function 'filter_mb_fast': h264.c:7074: warning: dereferencing type-punned pointer will break strict-aliasing rules
Hello, (In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? The code compiles and produces the expected result with -O1, O2, but can't be compiled with -O0: In file included from h264.c:36: cabac.h: In function 'get_cabac': cabac.h:454: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' cabac.h:454: error: 'asm' operand has impossible constraints h264.c: In function 'decode_cabac_residual': h264.c:6120: warning: initialization from incompatible pointer type > Besies above, I noticed that the asm in get_cabac looks to be clobbering memory > but is not marked as such. I can't really comment on that as I'm not too inline-asm fluent... however, I can say that this code can't be compiled without -fomit-frame-pointer. Is GCC supposed to produce valid code with this source to begin with? Guillaume
(In reply to comment #4) > (In reply to comment #3) > > Does it work when compiled with -O0 instead of -O4? How about -O1? > > > > Besies above, I noticed that the asm in get_cabac looks to be clobbering memory > > but is not marked as such. > > > > Andrew, this testcase violates aliasing rules. > > h264.c: In function 'filter_mb_fast': > h264.c:7074: warning: dereferencing type-punned pointer will break > strict-aliasing rules For what it's worth, the code around line 7074 compiled correctly with snapshot 4.2-20060909 and has been in FFmpeg since Mon Aug 28 09:33:01 2006 UTC, so IMHO it shouldn't be the cause of the problem I'm reporting today. However, if you have a suggestion to improve this code, I'm all ears Guillaume
(In reply to comment #3) > Does it work when compiled with -O0 instead of -O4? How about -O1? > > Besies above, I noticed that the asm in get_cabac looks to be clobbering memory > but is not marked as such. Damn, that was the bug. I don't quite understand why 4.0 and 4.1 weren't affected on Linux, whereas 3.4.6 was affected. Sorry for the trouble, and thanks for the great work! Guillaume