464.h264ref, 453.povray, and 482.sphinx3 Example: Running Benchmarks Running 464.h264ref ref base ppc64 default /home/seurer/gcc/cpu2006/bin/specinvoke -d /home/seurer/gcc/cpu2006/benchspec/CPU2006/464.h264ref/run/run_base_ref_ppc64.0000 -e speccmds.err -o speccmds.stdout -f speccmds.cmd -C -q /home/seurer/gcc/cpu2006/bin/specinvoke -E -d /home/seurer/gcc/cpu2006/benchspec/CPU2006/464.h264ref/run/run_base_ref_ppc64.0000 -c 1 -e compare.err -o compare.stdout -f compare.cmd *** Miscompare of foreman_ref_baseline_encodelog.out; for details see /home/seurer/gcc/cpu2006/benchspec/CPU2006/464.h264ref/run/run_base_ref_ppc64.0000/foreman_ref_baseline_encodelog.out.mis Invalid run; unable to continue.
Using -Ofast I presume? Note there's the 'match' debug-counter you can use to bisect the offending transform (per source file of course). Confirmed on a Haswell machine with -Ofast -march=native as well. Not exactly wrong-code confirmed yet but we'd like to have SPEC CPU "-Ofast clean" and thus need to understand what actual transform is bad here.
I can confirm that and I'm going to bisect the transformation.
Created attachment 46868 [details] Dump file with problematic transformation For the 453.povray (which fails with --size=test), the problematic file is: g++ -c -o quadrics.o -dspec_cpu -dndebug -ofast -g -fpermissive -dspec_cpu_lp64 quadrics.cpp -fdbg-cnt=match:4030 Where match:4030 is the first bad debug counter value.
Created attachment 46869 [details] Dump file without problematic transformation
The transformation is from: _663 = T1$1_55 + _293; _651 = (float) _663; where T1$1_55 and _293 are doubles. To: _758 = (float) T1$1_55; _759 = (float) _293; _760 = _758 + _759; _651 = (float) _760;
(In reply to Martin Liška from comment #5) > The transformation is from: > > _663 = T1$1_55 + _293; > _651 = (float) _663; > > where T1$1_55 and _293 are doubles. To: > > _758 = (float) T1$1_55; > _759 = (float) _293; > _760 = _758 + _759; > _651 = (float) _760; OK, so thats invalid for example when T1$1_55 and _293 are FP values that cannot be represented in 'float' but their sum can. That's outside of what we generally allow with -ffast-math. It would be valid if one of T1$1_55 or _293 are already float.
Note in all cases of the testcases coming with the patch the sources are eventually casted from float to double.
Reverted the patch.
Hmm yes the transformation is too aggressive and incorrect here. we'll fix that and resubmit a fixed patch.