Some change to trunk made in the last 18 days is making gcc miscompile the files libavcodec/jpeg2000dec.c libavcodec/j2kenc.c and libavcodec/avuidec.c from ffmpeg git head when -O3 is used. This doesn't happen with -O2. I tested with x86_64-pc-linux-gnu only. How to reproduce: git clone git://git.videolan.org/ffmpeg.git && cd ffmpeg && ./configure make fate-vsynth1-jpeg2000 fate-vsynth1-avui The tests will fail, the former showing both the encoder and decoder are producing garbage, and the latter only the decoder. Adding -fno-strict-aliasing -fwrapv does not make a difference. The command Makefile uses to compile all three files looks like this: gcc -I. -I/home/jamrial/ffmpeg/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H -std=c99 -fomit-frame-pointer -pthread -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -c -o OUTPUT.o INPUT.c You can get that kind of verbose output by running make with V=1. Keep in mind you'll probably run into pr67794 while bisecting gcc trunk to find the commit that introduced this regression. Apologizes for not having a simpler test case.
For reference you can also check http://fate.ffmpeg.org/report.cgi?time=20151010052205&slot=x86_64-archlinux-gcc-experimental
Can you also compile with -fsanitize=undefined and try that? Can you also try -fsanitize=address ? This might detect if it is a bug in the code vs a bug in GCC.
(In reply to Andrew Pinski from comment #2) > Can you also compile with -fsanitize=undefined and try that? Can you also > try -fsanitize=address ? > > This might detect if it is a bug in the code vs a bug in GCC. Can't check with gcc 6 because of pr67921, but asan/ubsan in gcc 5.2.0 and clang 3.1 apparently don't complain about the code. ubsan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010033356&slot=x86_64-archlinux-gcc-ubsan asan gcc 5.2.0: http://fate.ffmpeg.org/report.cgi?time=20151010181435&slot=x86_64-archlinux-gcc-asan Clang 3.1 asan: http://fate.ffmpeg.org/report.cgi?time=20151010171909&slot=x86_64-debian-asan-144800
Waiting for sth like a testcase.
This is a regression introduced by r228599. I'm attaching the output of -save-temps for all three files, the good assembly from r228598 (last good commit) and the bad assembly from r228599. I can't generate a better or simpler testcase, sorry.
Created attachment 36491 [details] -save-temps output for all three files
This should be the same as PR67947 which has a testcase.
Please check that revision 228760 will cure your issue.
(In reply to Yuri Rumyantsev from comment #8) > Please check that revision 228760 will cure your issue. Looks like it did. Thanks.
(In reply to James Almer from comment #9) > Looks like it did. Thanks. Fixed then