https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Tamar Christina from comment #11) > Historically it has always only been for the test dataset with the problem > Aldy encountered before with the signed zeros. See > https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html at the > section for GCC and -Ofast. > > train and ref used to work fine before. It may be perfectly valid that we > need it now for the rest too, but it's unclear to me if that's due to a new > valid transformation or an invalid one. Let's assume -ffast-math is supposed to work with ref for the time being, or until I run out of cycles :). I've reduced the failure to 2 jump threads, but unfortunately they're both correct, so we can only conclude the threader is correct. There could still be a latent bug downstream. Here are some notes on reproducing. Ref takes 15 minutes to complete, but the problematic output can be seen within the first minute. The NaN output is from the diffmail.pl execution diffmail.pl 4 800 10 17 19 300. The problem is Perl_pp_ge() in pp.c may be miscompiled. On r12-5346, it can be reduced to: $ rm pp.o $ specmake OPTIMIZE="-O3 -ffast-math -fdisable-tree-threadfull2 -fdisable-tree-ethread -fdisable-tree-thread1 -fdisable-tree-thread2 -fno-tree-dominator-opts -fdbg-cnt=registered_jump_thread:173-173:175-175" That is, turn off all jump threaders except threadfull1. If we look for dbgcnt in pp.c.111t.threadfull1, we can see: ***dbgcnt: lower limit 173 reached for registered_jump_thread.*** ***dbgcnt: upper limit 173 reached for registered_jump_thread.*** [173] Registering jump thread: (36, 39) incoming edge; (39, 40) normal (40, 42) nocopy; path: 36->39->40->42 SUCCESS This corresponds to this path: =========== BB 36 ============ <bb 36> [local count: 584543650]: if (iftmp.546_109 < iftmp.547_110) goto <bb 39>; [34.00%] else goto <bb 37>; [66.00%] =========== BB 39 ============ <bb 39> [local count: 787582387]: # _111 = PHI <_69(20), -1(35), _77(23), _88(25), 1(36), _98(28), 2(37), 0(38), 1(26), -1(21)> _18 = _111 & 2; iftmp.533_35 = _18 == 0; =========== BB 40 ============ <bb 40> [local count: 953267993]: # iftmp.533_22 = PHI <iftmp.533_33(7), iftmp.533_35(39)> if (iftmp.533_22 != 0) goto <bb 42>; [50.00%] else goto <bb 41>; [50.00%] We can clearly conclude iftmp.533_22 != 0 and thread through BB42. The #175 thread is a virtually identical sequence. Both are correct.
