[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" <gcc-bugzilla@gcc.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 ....