Can be seen on a Ryzen machine and Haswell with following flags: OPTIMIZE = -Ofast -march=native -g -flto=8 CXXOPTIMIZE = -fpermissive FOPTIMIZE = -std=legacy PASS1_OPTIMIZE = -fprofile-generate PASS2_OPTIMIZE = -fprofile-use -fprofile-correction I'm bisecting problematic revision.
What a surprise, started with r267883. I'll carry on bisection with --param inline-unit-growth=40.
> What a surprise, started with r267883. I'll carry on bisection with --param > inline-unit-growth=40. Well, I guess I can't claim that this is not gcc bug but it is the benchmark that is broken :) Honza
Is this the same as PR 87214?
(In reply to H.J. Lu from comment #3) > Is this the same as PR 87214? No, this one is probably related to RPO VN, I'm not finished with bisection. And it also happens on non-avx512 targets.
Started with r263875: Setting Up Run Directories Setting up 502.gcc_r refrate (ref) peak gcc7-m64 (1 copy): run_peak_refrate_gcc7-m64.0002 Running Benchmarks Running 502.gcc_r refrate (ref) peak gcc7-m64 (1 copy) [2019-01-18 15:34:36] Error with '/home/marxin/Programming/cpu2017/bin/specinvoke -d /home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002 -f compare.cmd -E -e compare.err -o compare.stdout'; no non-empty output files exist Command returned exit code 1 **************************************** Contents of gcc-pp.opts-O2_-finline-limit_36000_-fpic.err **************************************** gcc-pp.c: In function 'fibheap_delete_node': gcc-pp.c:19958:49: warning: overflow in implicit constant conversion gcc-pp.c: In function 'htab_mod_1': gcc-pp.c:25469:7: warning: right shift count >= width of type gcc-pp.c: At top level: gcc-pp.c:463503:13: warning: 'compute_transp' used but never defined gcc-pp.c:463518:12: warning: 'one_cprop_pass' used but never defined gcc-pp.c:463534:12: warning: 'one_pre_gcse_pass' used but never defined gcc-pp.c:463542:12: warning: 'one_code_hoisting_pass' used but never defined gcc-pp.c:463551:25: warning: 'find_rtx_in_ldst' used but never defined gcc-pp.c:463579:13: warning: 'store_motion' used but never defined gcc-pp.c:463582:13: warning: 'free_modify_mem_tables' used but never defined gcc-pp.c:463588:22: warning: 'is_too_expensive' used but never defined **************************************** **************************************** Contents of gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.err **************************************** gcc-pp.c: In function 'fibheap_delete_node': gcc-pp.c:19958:49: warning: overflow in implicit constant conversion gcc-pp.c: In function 'htab_mod_1': gcc-pp.c:25469:7: warning: right shift count >= width of type gcc-pp.c: At top level: gcc-pp.c:463503:13: warning: 'compute_transp' used but never defined gcc-pp.c:463518:12: warning: 'one_cprop_pass' used but never defined gcc-pp.c:463534:12: warning: 'one_pre_gcse_pass' used but never defined gcc-pp.c:463542:12: warning: 'one_code_hoisting_pass' used but never defined gcc-pp.c:463551:25: warning: 'find_rtx_in_ldst' used but never defined gcc-pp.c:463579:13: warning: 'store_motion' used but never defined gcc-pp.c:463582:13: warning: 'free_modify_mem_tables' used but never defined gcc-pp.c:463588:22: warning: 'is_too_expensive' used but never defined **************************************** **************************************** Contents of gcc-smaller.opts-O3_-fipa-pta.err **************************************** gcc-smaller.c: In function 'fibheap_delete_node': gcc-smaller.c:19958:49: warning: overflow in implicit constant conversion gcc-smaller.c: In function 'htab_mod_1': gcc-smaller.c:25469:7: warning: right shift count >= width of type **************************************** **************************************** Contents of ref32.opts-O3_-fselective-scheduling_-fselective-scheduling2.err **************************************** ref32.c:6213:17: warning: conflicting types for built-in function 'imaxabs' **************************************** **************************************** Contents of ref32.opts-O5.err **************************************** ref32.c:6213:17: warning: conflicting types for built-in function 'imaxabs' **************************************** *** Miscompare of gcc-smaller.opts-O3_-fipa-pta.s; for details see /home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-smaller.opts-O3_-fipa-pta.s.mis *** Miscompare of gcc-pp.opts-O2_-finline-limit_36000_-fpic.s; for details see /home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-pp.opts-O2_-finline-limit_36000_-fpic.s.mis *** Miscompare of gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.s; for details see /home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/run/run_peak_refrate_gcc7-m64.0002/gcc-pp.opts-O3_-finline-limit_0_-fif-conversion_-fif-conversion2.s.mis I'll work on that next week and I'll try find the problem.
I first isolated minimal test-case for which I can see the miscompilation of the benchmark compiler: $ cat scilab.c int a, b, c, d; void e() { a = (d >= c ? d : c) - 1 + b; } $ bash -x ./reduce-ice.sh scilab.c + TC1=scilab.c + /home/marxin/Programming/cpu2017/benchspec/CPU/502.gcc_r/build/build_peak_gcc7-m64.0000/cpugcc_r scilab.c -fpic -o 1.s + test 0 = 0 + /tmp/502gcc/build/build_peak_gcc7-m64.0000/cpugcc_r scilab.c -fpic -o 2.s + test 0 = 0 + diff -u 1.s 2.s --- 1.s 2019-01-23 12:36:20.815829891 +0100 +++ 2.s 2019-01-23 12:36:20.831830396 +0100 @@ -4,26 +4,23 @@ .globl e .type e, @function e: + call __i686.get_pc_thunk.cx + addl $_GLOBAL_OFFSET_TABLE_, %ecx pushl %ebp movl %esp, %ebp - pushl %ebx - call __i686.get_pc_thunk.bx - addl $_GLOBAL_OFFSET_TABLE_, %ebx - movl b@GOT(%ebx), %eax - movl (%eax), %ecx - movl d@GOT(%ebx), %eax - subl $1, %ecx + movl d@GOT(%ecx), %eax movl (%eax), %edx - movl c@GOT(%ebx), %eax + movl c@GOT(%ecx), %eax ... Not I'm going to find a minimal set of LTO object files needed.
Using -flto only for tree-ssa-reassoc.o produces the miscompiled GCC (other files are takes from -O2 -fno-lto build).
Ok, compiled binary differs in spec_qsort. That's a known problem and we should use -fno-strict-aliasing. As mentioned here: https://www.spec.org/cpu2017/Docs/benchmarks/502.gcc_r.html I'm testing that..
Yes, -fno-strict-aliasing works!
On Wed, 23 Jan 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900 > > Martin Liška <marxin at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|ASSIGNED |RESOLVED > Resolution|--- |INVALID > > --- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> --- > Yes, -fno-strict-aliasing works! You can also try the specifc source fix to spec_qsort which IIRC I attached somewhere...
(In reply to rguenther@suse.de from comment #10) > On Wed, 23 Jan 2019, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88900 > > > > Martin Liška <marxin at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Status|ASSIGNED |RESOLVED > > Resolution|--- |INVALID > > > > --- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> --- > > Yes, -fno-strict-aliasing works! > > You can also try the specifc source fix to spec_qsort which IIRC > I attached somewhere... Yep, it's this patch: https://github.com/freebsd/freebsd/commit/26c8a03901f609258e58c4e3bfdc981962a638f0#diff-a8e4a78e4bb28c6e0fe9561688f51573