[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.