After investigation of a suspected graphics-driver bug, it was found that the issue lay with gcc. Please see https://bugs.freedesktop.org/show_bug.cgi?id=47559 . The problem as I understand is that gcc-4.6.0 miscompiles miarc.c from the xorg-server package if -ftree-vectorize is enabled. This flag is enabled with -O3. The following minimal set of CFLAGS worked: "-g -O2" Adding the -ftree-vectorize separately, "-g -O2 -ftree-vectorize", caused the program to misbehave at runtime. I am running gentoo, the default CFLAGS for my system are: CFLAGS="-march=native -O3 -pipe -fomit-frame-pointer -fweb -ffast-math -mtune=native -mfpmath=sse" I don't know if these match exactly with what is passed by portage for compiling GCC. Software versions (gentoo package versions): sys-devel/gcc-4.6.0 x11-base/xorg-server-1.11.2-r2 My hardware is a Dell XPS 15 (L502x) laptop with a 'Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz' I additional information is required please let me know.
(In reply to comment #0) > I additional information is required please let me know. Please provide all necessary information, as outlined in [1]. [1] http://gcc.gnu.org/bugs/#report
Created attachment 27220 [details] .i version of miarc.c I think this is the information that was missing: The file in question compiled with CFLAGS="-O3 -pipe -fomit-frame-pointer -fweb -ffast-math -mtune=native -mfpmath=sse" (attached) gcc build options: >>> Compiling source in /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0 ... * CFLAGS="-march=native -pipe -mtune=native -O2" * CXXFLAGS="-march=native -pipe -mtune=native -O2" * Configuring gcc ... * configuring for GCC_LANG: c,c++,fortran * PREFIX: /usr * BINPATH: /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0 * LIBPATH: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0 * DATAPATH: /usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0 * STDCXX_INCDIR: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4 * Configuring GCC with: * --prefix=/usr * --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0 * --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include * --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0 * --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man * --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info * --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4 * --host=x86_64-pc-linux-gnu * --build=x86_64-pc-linux-gnu * --disable-altivec * --disable-fixed-point * --with-ppl * --with-cloog * --disable-ppl-version-check * --with-cloog-include=/usr/include/cloog-ppl * --enable-lto * --enable-nls * --without-included-gettext * --with-system-zlib * --disable-werror * --enable-secureplt * --disable-multilib * --disable-libmudflap * --disable-libssp * --enable-libgomp * --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python * --enable-checking=release * --disable-libgcj * --enable-languages=c,c++,fortran * --enable-shared * --enable-threads=posix * --enable-__cxa_atexit * --enable-clocale=gnu * --enable-targets=all * --with-bugurl=http://bugs.gentoo.org/ * --with-pkgversion=Gentoo 4.6.0 p1.2, pie-0.4.5 Compiler does not seem to output anything relevant (no errors, compilation is successful).
gcc -v output: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5' Thread model: posix gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5)
Unfortunately, this is a runtime failure, so we will also need a runtime testcase (probably minimized) that fails when compiled with options that expose the bug. In comment #8 of the linked bugreport, you have testing failures, so this is a good starting point to locate the problem.
BTW: Can you test if this problem is still present in a newer version of the compiler (i.e. 4.6.3 or 4.7.0)?
(In reply to comment #5) > BTW: Can you test if this problem is still present in a newer version of the > compiler (i.e. 4.6.3 or 4.7.0)? I've tried to take the source-file in question (miarc.c) and make something self-contained, but I was unable to make it work due to this being an internal xorg-file, apparently using and depending on internal headers. If you have any pointers on how to tackle such a situation to convert it to something selfcontained I'd be happy to try it out. The latest available gcc-version for my distribution (gentoo) appears to be 4.6.2, which I will try next.
(In reply to comment #6) ... > The latest available gcc-version for my distribution (gentoo) appears to be > 4.6.2, which I will try next. This seems to still happen with 4.6.2 at least.
(In reply to comment #6) > I've tried to take the source-file in question (miarc.c) and make something > self-contained, but I was unable to make it work due to this being an internal > xorg-file, apparently using and depending on internal headers. If you have any > pointers on how to tackle such a situation to convert it to something > selfcontained I'd be happy to try it out. First, prepare some test input and call failing function. Compare its result with some reference result and abort () if the result is not expected. The preprocessed file is self-contained, so you could just compile it and link into executable. Starting from here, you remove portions of the function that are not needed (i.e. unreachable if branches, switch cases, etc...) for test input. Maybe you could ask Gentoo compiler maintainer for help...
(In reply to comment #8) > > I've tried to take the source-file in question (miarc.c) and make something > > self-contained, but I was unable to make it work due to this being an internal > > xorg-file, apparently using and depending on internal headers. If you have any > > pointers on how to tackle such a situation to convert it to something > > selfcontained I'd be happy to try it out. > > First, prepare some test input and call failing function. Compare its result > with some reference result and abort () if the result is not expected. The > preprocessed file is self-contained, so you could just compile it and link into > executable. You can obtain reference result by running the function, compiled with non-failing compile flags.
Youo can start from [1], you have a failing output there, just provide some reference input to failing function. [1] https://bugs.freedesktop.org/show_bug.cgi?id=47559#c8
Created attachment 30419 [details] main.c We've also been hitting this, so here is a reduced test case to provoke the bug. Output in the failing case: test_spans(nspans=36) 101,100 + 1 101,0 + 1 0,100 + 0 Aborted (core dumped) And for a correct run: test_spans(nspans=36) 101,100 + 1 101,100 + 1 101,100 + 1 101,100 + 1 101,101 + 1 101,101 + 1 101,99 + 1 101,99 + 1 101,102 + 1 ...
Created attachment 30420 [details] Makefile
This was tested using gcc 4.7.2 and gcc 4.5.3.
(In reply to Pierre Ossman from comment #11) > Created attachment 30419 [details] > main.c > > We've also been hitting this, so here is a reduced test case to provoke the > bug. Output in the failing case: > > test_spans(nspans=36) > 101,100 + 1 > 101,0 + 1 > 0,100 + 0 > Aborted (core dumped) > > > And for a correct run: > > test_spans(nspans=36) > 101,100 + 1 > 101,100 + 1 > 101,100 + 1 > 101,100 + 1 > 101,101 + 1 > 101,101 + 1 > 101,99 + 1 > 101,99 + 1 > 101,102 + 1 > ... The program runs successfully for me with both the "ok" and the "fail" sets of CFLAGS, as well as the CFLAGS you listed in your original report. I can't reproduce the bug with gcc8, so I'm closing this as WORKSFORME.