[Bug other/103088] New: [12 regression] 500.perlbench from spec 2017 fails since r12-4698

[Bug other/103088] New: [12 regression] 500.perlbench from spec 2017 fails since r12-4698

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

            Bug ID: 103088
           Summary: [12 regression] 500.perlbench from spec 2017 fails
                    since r12-4698
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:f6d012338bf87f427b7420f2f309963c29fe33ba, r12-4698

commit f6d012338bf87f427b7420f2f309963c29fe33ba (HEAD)
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 20 07:29:25 2021 +0200

    Try to resolve paths in threader without looking further back.


I am seeing a strange problem starting with this revision.  The spec 2017 test
case 500.perlbench is producing a few extraneous lines of output which is
causing it to fail.

seurer@muskie:~/gcc/cpu2017$ diff
./benchspec/CPU/500.perlbench_r/data/refrate/output/diffmail.4.800.10.17.19.300.out

./benchspec/CPU/500.perlbench_r/run/run_peak_refrate_none.0000/diffmail.4.800.10.17.19.300.out
3257a3258
> Minimum abstol: nan       
3259a3261
> Minimum reltol: nan       
3507a3510
> Minimum abstol: nan       
3509a3513
> Minimum reltol: nan       
3694a3699
> Minimum abstol: nan       
3696a3702
> Minimum reltol: nan       
3818a3825
> Minimum abstol: nan       
3820a3828
> Minimum reltol: nan       


These extra lines come from here in the perl code:

    if ($opts->{'calctol'}) {
        push @errstats, 'Calculated tolerances:';
        foreach my $type (qw(abstol reltol obiwan skiptol)) {
            if (exists($max->{$type}) && ($max->{$type} >= 0)) {
                push @errstats, sprintf "Maximum $type: %-10.5e",
$max->{$type};
            }
            if (exists($min->{$type}) && ($min->{$type} >= 0)) {
                push @errstats, sprintf "Minimum $type: %-10.5e",
$min->{$type};
            }
            if (exists($errcnt->{$type}) && ($errcnt->{$type} >= 0)) {
                push @errstats, "# of $type errors: ".$errcnt->{$type};
            }
            if (exists($opts->{"skip$type"}) && ($opts->{"skip$type"} > 0)) {
                push @errstats, "# of skip$type unused: ".$opts->{"skip$type"};
            }
        }
    }

So it appears that either the results of the perl exists function changed or
the values that are being checked did not exist before but do now.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |tree-optimization
   Target Milestone|---                         |12.0
           Keywords|                            |wrong-code

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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-05
             Blocks|                            |26163
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
What compiler options do you use?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

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

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #2 from seurer at gcc dot gnu.org ---
One of the ocmpilations was this:

/home/seurer/gcc/git/install/gcc-test/bin/gcc -c -o ext/re/re_comp.o -DSPEC
-DNDEBUG -DPERL_CORE -I. -Idist/IO -Icpan/Time-HiRes -Icpan/HTML-Parser
-Iext/re -Ispecrand -DDOUBLE_SLASHES_SPECIAL=0 -DSPEC_AUTO_SUPPRESS_OPENMP
-D_LARGE_FILES -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -m64 -O3
-mcpu=power9 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model
-mpopcntd -mrecip=rsqrt        -DSPEC_LP64 -Wno-deprecated-declarations
-DSPEC_LINUX_PPC_LE      -D_XOPEN_SOURCE=500 -fno-strict-aliasing 
ext/re/re_comp.c

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-none-linux-gnu
                 CC|                            |tnfchris at gcc dot gnu.org
              Build|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-none-linux-gnu
             Target|powerpc64le-linux-gnu       |powerpc64le-linux-gnu,
                   |                            |aarch64-none-linux-gnu

--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
I'm seeing the same failure on aarch64-none-linux-gnu

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Is this still an issue with the latest trunk? There have been a few changes in
this space (phi ordering, loop header copying, etc).

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> Is this still an issue with the latest trunk? There have been a few changes
> in this space (phi ordering, loop header copying, etc).

At least on aarch64 our nightlies are still miscompiling perlbench, and the new
lines are still there, but I can't rule out of something else didn't cause the
issue again.

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

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #6 from seurer at gcc dot gnu.org ---
I am still seeing the failure on powerpc64 with current trunk (r12-5320), too.

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Could someone post the relevant configury bits used for the ppc64le case.

For example, I have:

   OPTIMIZE    = -O3 -m64 -mcpu=power9 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd -mrecip=rsqrt

My inherited config file also has the following for the 500.perlbench test:

   EXTRA_OPTIMIZE      = -fno-strict-aliasing -fno-unsafe-math-optimizations^M

I noticed as per comment #2, that seurer's doesn't add
-fno-unsafe-math-optimizations.

Also, what runcpu flags are used?

I used:

runcpu --config=myconfig -a validate --iterations=1  --ignore-errors --rebuild
--noreportable -i test --tune=base 500.perlbench

...which fails in an altogether different manner:

****************************************
Contents of test.err
****************************************
op/sprintf2.t   not ok 1457 - negative zero
op/sprintf2.t|  # Failed test 1457 - negative zero at op/sprintf2.t line 701
op/sprintf2.t|  #      got "0x0p+0"
op/sprintf2.t|  # expected "-0x0p+0"
op/sprintf2.t   not ok 1458 - negative zero
op/sprintf2.t|  # Failed test 1458 - negative zero at op/sprintf2.t line 702
op/sprintf2.t|  #      got "+0x0p+0"
op/sprintf2.t|  # expected "-0x0p+0"
op/sprintf2.t   not ok 1459 - negative zero
op/sprintf2.t|  # Failed test 1459 - negative zero at op/sprintf2.t line 703
op/sprintf2.t|  #      got "0x0.0000000000000p+0"
op/sprintf2.t|  # expected "-0x0.0000000000000p+0"
Failed 1 test out of 317, 99.68% okay.

Is the above what y'all are getting, or is the "Minimum abstol: nan" message
totally different?

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #8 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #7)
> Could someone post the relevant configury bits used for the ppc64le case.
> 
> I used:
> 
> runcpu --config=myconfig -a validate --iterations=1  --ignore-errors
> --rebuild --noreportable -i test --tune=base 500.perlbench
> 

The test dataset has extra checks that check differences between signed and
unsigned zero which -ffast-math turns on and `-fno-unsafe-math-optimizations`
doesn't turn off.  You'll want to do a ref run instead,

so either `-i ref` or just drop the `-i` entirely, since you've already
specified `--noreportable` it won't do the `train and ref` automatically.  The
test dataset is also likely too small to show the issue.

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I can reproduce this with -i ref with -O3 -ffast-math but not with -O3
-fno-unsafe-math-optimizations.

Richi the configury bits you shared once upon a time had
-fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
this test for -ffast-math that we had -fno-unsafe-math-optimizations?

I just wanna know before I go down the rabbit hole ;-).

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

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 18 Nov 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> I can reproduce this with -i ref with -O3 -ffast-math but not with -O3
> -fno-unsafe-math-optimizations.
> 
> Richi the configury bits you shared once upon a time had
> -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> this test for -ffast-math that we had -fno-unsafe-math-optimizations?

Indeed - interesting.  I don't remember anything and I have originally
copied this config from our testers which means iff then maybe
Martin knows ... ;)

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #11 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
> > Richi the configury bits you shared once upon a time had
> > -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> > this test for -ffast-math that we had -fno-unsafe-math-optimizations?
> 
> Indeed - interesting.  I don't remember anything and I have originally
> copied this config from our testers which means iff then maybe
> Martin knows ... ;)

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.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 103318 has been marked as a duplicate of this bug. ***

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

[aldyh at gcc dot 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.

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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
> > Richi the configury bits you shared once upon a time had
> > -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> > this test for -ffast-math that we had -fno-unsafe-math-optimizations?
> 
> Indeed - interesting.  I don't remember anything and I have originally
> copied this config from our testers which means iff then maybe
> Martin knows ... ;)

Yes, I can confirm we have 

   EXTRA_OPTIMIZE      = -fno-strict-aliasing -fno-unsafe-math-optimizations

for perlbench benchmark. It's also mentioned in portability Issues:
https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html

```
3. GCC -Ofast and unsafe math: Users of GCC's -Ofast option may encounter
problems with the test workload failing to validate. If you go to the run
directory and look at file test.out.mis, you may see output such as:
...
```

So I would close this as invalid as it's a known limitation.

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #14)
> > > Richi the configury bits you shared once upon a time had
> > > -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> > > this test for -ffast-math that we had -fno-unsafe-math-optimizations?
> > 
> > Indeed - interesting.  I don't remember anything and I have originally
> > copied this config from our testers which means iff then maybe
> > Martin knows ... ;)
> 
> Yes, I can confirm we have 
> 
>    EXTRA_OPTIMIZE      = -fno-strict-aliasing -fno-unsafe-math-optimizations
> 
> for perlbench benchmark. It's also mentioned in portability Issues:
> https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html
> 
> ```
> 3. GCC -Ofast and unsafe math: Users of GCC's -Ofast option may encounter
> problems with the test workload failing to validate. If you go to the run
> directory and look at file test.out.mis, you may see output such as:
> ...
> ```
> 
> So I would close this as invalid as it's a known limitation.

Well, the output mentioned in the PR is not exactly the validation error in the
above link, but I'm not going to argue.

For the record, the underlying problem is the inlining of Perl_do_ncmp() into
Perl_pp_ge().  Interestingly it has some NaN checking code.

Now can someone give me back the 5 hours I've spent on this ;-).

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #16 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #14)
> > > Richi the configury bits you shared once upon a time had
> > > -fno-unsafe-math-optimizations for 500.perlbench.  Are there known issues with
> > > this test for -ffast-math that we had -fno-unsafe-math-optimizations?
> > 
> > Indeed - interesting.  I don't remember anything and I have originally
> > copied this config from our testers which means iff then maybe
> > Martin knows ... ;)
> 
> Yes, I can confirm we have 
> 
>    EXTRA_OPTIMIZE      = -fno-strict-aliasing -fno-unsafe-math-optimizations
> 
> for perlbench benchmark. It's also mentioned in portability Issues:
> https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html
> 
> ```
> 3. GCC -Ofast and unsafe math: Users of GCC's -Ofast option may encounter
> problems with the test workload failing to validate. If you go to the run
> directory and look at file test.out.mis, you may see output such as:
> ...
> ```
> 
> So I would close this as invalid as it's a known limitation.

I Disagree. Your text explicitly says "with the test workload failing to
validate".

this PR was about a new failure appearing with the ref workload. The spec
portability section does not mention ref as ref used to work fine.

I don't mind closing this as invalid, however this isn't a known limitation,
it's a new limitation.

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

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #17 from Martin Liška <marxin at gcc dot gnu.org> ---
> I don't mind closing this as invalid, however this isn't a known limitation,
> it's a new limitation.

Yes, it may be a new limitation or we may be affected by the same issue by now
for ref size.

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #18 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #17)
> > I don't mind closing this as invalid, however this isn't a known limitation,
> > it's a new limitation.
> 
> Yes, it may be a new limitation or we may be affected by the same issue by
> now for ref size.

Yes, which is why I had asked for us to confirm[1] that the reason for the
failure is valid since the failure appeared on a non-math related patch :)

If Aldy is happy that the threader is correct here I'm happy with that. The
previous failures were well understood.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088#c11

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Ughh, I was nerd sniped.  Couldn't let it go ;-).

The problem is this construct in Perl_do_ncmp:

      if (lnv < rnv)
        return -1;
      if (lnv > rnv)
        return 1;
      if (lnv == rnv)
        return 0;
      return 2;

These are all doubles.  The code is depending on a pair of values that are
neither <, >, nor ==, being a NAN.

For -ffast-math with unsafe optimizations we end up inling Perl_do_ncmp into
pp_ge():

SETs(boolSV(
        (SvIOK_notUV(left) && SvIOK_notUV(right))
        ? (SvIVX(left) >= SvIVX(right))
        : ( (do_ncmp(left, right) & 2) == 0)
    ));

but in doing so we destroy the 3 separate conditionals.  At one point we're
making decisions based on <= on the 35->38 edge:

struct OP * Perl_pp_ge ():
...
  <bb 35> [local count: 590686791]:
  # iftmp.547_110 = PHI <iftmp.547_107(33), iftmp.547_108(34)>
  if (iftmp.546_109 > iftmp.547_110)
    goto <bb 23>; [1.04%]
  else
    goto <bb 38>; [98.96%]

<snip>
<snip>

  <bb 38> [local count: 644407314]:

  <bb 39> [local count: 953267993]:
  # iftmp.532_21 = PHI <&PL_sv_yes(38), &PL_sv_no(37)>
  MEM[(struct SV * *)sp_27 + -8B] = iftmp.532_21;
  PL_stack_sp = sp_30;
  PL_op.534_19 = PL_op;
  _38 = PL_op.534_19->op_next;

  <bb 40> [local count: 1073741826]:
  # _20 = PHI <_29(5), _38(39)>
  return _20;

For -fno-unsafe-math-optimizations we avoid inlining Perl_no_ncmp, which keeps
the conditionals.

So it looks like we inline the NAN checking code in unsafe mode and the
threader ends can make decisions on the return value for pp_ge().  As I said,
the threads are correct.

If anyone is curious, you can see what's going on by tagging Perl_do_ncmp()
with __attribute__((optimize("O3", "fast-math",
"no-unsafe-math-optimizations")))

and seeing the final pp_ge() output with the munged conditionals versus the
pristine code in the output for Perl_do_ncmp.

I think we can keep this PR closed.  Don't use -ffast-math unless followed by
-fno-unsafe-math-optimizations.

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #20 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #19)
> Ughh, I was nerd sniped.  Couldn't let it go ;-).
> 
> The problem is this construct in Perl_do_ncmp:
> 
>       if (lnv < rnv)
>         return -1;
>       if (lnv > rnv)
>         return 1;
>       if (lnv == rnv)
>         return 0;
>       return 2;
> 
> These are all doubles.  The code is depending on a pair of values that are
> neither <, >, nor ==, being a NAN.

And...you can work around the problem by declaring the doubles volatile ;-):

      volatile NV const rnv = SvNV_nomg(right);
      volatile NV const lnv = SvNV_nomg(left);
...
...
      if (lnv < rnv)
        return -1;
      if (lnv > rnv)
        return 1;
      if (lnv == rnv)
        return 0;
      return 2;

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

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #21 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
One last comment.

A smaller hammer than -fno-unsafe-math-optimizations may be
-fno-finite-math-only which allows for the problematic NAN behavior in
Perl_do_ncmp.  Allowing for the inlining, but not munging the comparisons.  For
that matter, the test passes for ref with it.

Though someone more knowledgeable with perl+math should opine here.  I don't
know if NAN / INF are the only issues in this test wrt -ffast-math.

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

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 19 Nov 2021, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
> 
> --- Comment #19 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> 
> The problem is this construct in Perl_do_ncmp:
> 
>       if (lnv < rnv)
>         return -1;
>       if (lnv > rnv)
>         return 1;
>       if (lnv == rnv)
>         return 0;
>       return 2;
> 
> These are all doubles.  The code is depending on a pair of values that are
> neither <, >, nor ==, being a NAN.

It would be nice from a QOI point of view (aka DWIM) that even with
-ffast-math we'd recognize this as a form of FP classification since
"obviously" the intent was to handle the NaN special case.  Not that
I see any reasonable way to represent the NaN case in -ffast-math IL ...

> I think we can keep this PR closed.  Don't use -ffast-math unless followed by
> -fno-unsafe-math-optimizations.

Agreed.

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

--- Comment #23 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks Aldy!

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

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org

--- Comment #24 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #22)
> It would be nice from a QOI point of view (aka DWIM) that even with
> -ffast-math we'd recognize this as a form of FP classification since
> "obviously" the intent was to handle the NaN special case.

How can that be "obviously" the intent if the user explicitly said there
*are* no NaNs?!

Do we want a warning for this?  Not that I see how this can be sanely
implemented ;-)

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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guojiufu at gcc dot gnu.org

--- Comment #25 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 106928 has been marked as a duplicate of this bug. ***