[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
Mon Sep 26 10:53:00 GMT 2022
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 ....
More information about the Gcc-bugs
mailing list