[Bug tree-optimization/107021] New: [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[Bug tree-optimization/107021] New: [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[marxin at gcc dot gnu.org]

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

            Bug ID: 107021
           Summary: [13 Regression] 511.povray_r error with -Ofast
                    -march=znver2 -flto since r13-2810-gb7fd7fb5011106
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: aldyh at gcc dot gnu.org
            Blocks: 26163
  Target Milestone: ---

Since the revision, the benchmark is likely miscompiled.

Running Benchmarks
  Running 511.povray_r test peak gcc-m64 (1 copy) [2022-09-23 22:12:20]
511.povray_r: copy 0 non-zero return code (exit code=1, signal=0)


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/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Btw. since the same revision fails TSVC's s1281 w/ -march=znver2 -Ofast. Maybe
it will be smaller reproducer.

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You need -fno-finite-math-only now.

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw,

make check-gcc RUNTESTFLAGS="--target_board=unix/-march=znver2/-Ofast
vect.exp=vect-tsvc-s1281.c"

doesn't work to reproduce since the harness appends -O2, but I can reproduce
with -Ofast -mavx2 on trunk.

value: inf, expected: inf

because

    } else if (!strcmp(name, "s1281")) {
        return INFINITY;

and

tatic _Bool is_checksum_same(real_t expected, real_t value)
{
  if (expected == INFINITY)
      return value == INFINITY;

is likely optimized away and we end up in

  else {
      real_t fraction = value / expected;
      return 0.99f <= fraction && fraction <= 1.01f;

so I'd call that a testsuite issue.

Do we know what goes wrong with povray?

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-09-26

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Yep, it exits here:

#0  __GI_exit (status=1) at exit.c:142
#1  0x00000000002b0961 in povray_exit (i=1) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/povray.cpp:486
#2  0x00000000002e3ede in pov::Error (format=<optimized out>) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/userio.cpp:365
#3  0x0000000000270f16 in pov::Parse_Camera (Camera_Ptr=<optimized out>) at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:1423
#4  0x000000000028083f in pov::Parse_Frame () at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:6125
#5  0x00000000002c0557 in pov::Parse () at
/home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/build_peak_gcc-m64.0002/parse.cpp:289

parse.cpp contains:

where New->Angle is infinite as assigned here:
1180            New->Angle = HUGE_VAL;

#if __GNUC_PREREQ (3, 3)
# define HUGE_VAL (__builtin_huge_val ())
#else

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
>
> so I'd call that a testsuite issue.
> 

Yep, how should I fix the verifier? Just skip it if the expected value is
infinite?

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #5)
> >
> > so I'd call that a testsuite issue.
> > 
> 
> Yep, how should I fix the verifier? Just skip it if the expected value is
> infinite?

No, don't build it with -fno-finite-math-only?

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Martin Liška from comment #5)
> > >
> > > so I'd call that a testsuite issue.
> > > 
> > 
> > Yep, how should I fix the verifier? Just skip it if the expected value is
> > infinite?
> 
> No, don't build it with -fno-finite-math-only?

That's fine for TSVC, I can adjust that. The question is what to do with
511.povray_r as we want to support SPECs with -Ofast.

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #4)
> Yep, it exits here:
> 
> #0  __GI_exit (status=1) at exit.c:142
> #1  0x00000000002b0961 in povray_exit (i=1) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/povray.cpp:486
> #2  0x00000000002e3ede in pov::Error (format=<optimized out>) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/userio.cpp:365
> #3  0x0000000000270f16 in pov::Parse_Camera (Camera_Ptr=<optimized out>) at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:1423
> #4  0x000000000028083f in pov::Parse_Frame () at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:6125
> #5  0x00000000002c0557 in pov::Parse () at
> /home/marxin/Programming/cpu2017/benchspec/CPU/511.povray_r/build/
> build_peak_gcc-m64.0002/parse.cpp:289
> 
> parse.cpp contains:
> 
> where New->Angle is infinite as assigned here:
> 1180		New->Angle = HUGE_VAL;
> 
> #if __GNUC_PREREQ (3, 3)
> # define HUGE_VAL (__builtin_huge_val ())
> #else

And the code that fails is guarded with

                // apply "angle"
                if (New->Angle != HUGE_VAL)
                {
                        if ((New->Type == PERSPECTIVE_CAMERA) || (New->Type ==
ORTHOGRAPHIC_CAMERA))
                        {
                                if (New->Angle >= 180.0)
                                        Error("Viewing angle has to be smaller
than 180 degrees.");

so it's somewhat "bad QOI" if we optimize

  mem = Inf;
  if (mem != Inf)
    abort ();

with -ffinite-math-only because in some way there's no "math" involved here :P
But yeah, the above is just a cheap isinf() which we'd have folded before
and now we're folding the literal equality compare as well.

Meh.

-ffinite-math-only was supposed to give us leverage in associating ops and
not wory about turning +Inf into something else, like x + x - x is +Inf
if x + x overflows but we like to optimize it to 'x'.  That is, it was
more relaxing arithmetic folding than saying "any Inf invokes undefined
behavior".

The docs still say

@item -ffinite-math-only
@opindex ffinite-math-only
Allow optimizations for floating-point arithmetic that assume
that arguments and results are not NaNs or +-Infs.

blindly breaking programs without benefit isn't really what we should do,
but then this ship may have sailed ....

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[pinskia at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/107021] [13 Regression] 511.povray_r error with -Ofast -march=znver2 -flto since r13-2810-gb7fd7fb5011106

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not a bug.