[Bug middle-end/102129] New: -ftrapping-math is broken or badly documented

[Bug middle-end/102129] New: -ftrapping-math is broken or badly documented

[vincent-gcc at vinc17 dot net]

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

            Bug ID: 102129
           Summary: -ftrapping-math is broken or badly documented
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Testcase:

void g (void);
double f (double x)
{
  double r = x * 5.0;
  g ();
  return r;
}

In the generated code with -O1 and above, one can see that the multiplication
is done after g is called, even if -ftrapping-math is used (which is the
default). This is incorrect as x * 5.0 may trap, terminating the program with a
floating-point exception, in which case g must not be executed.

There is a similar discussion in PR29186 (which is actually about flag
reading), and -ftrapping-math is also mentioned in PR34678 ("I suspect that if
-ftrapping-math actually implemented everything required for the floating-point
exceptions aspects of FENV_ACCESS, [...]").

The STDC FENV_ACCESS pragma is not implemented, but by definition of
-ftrapping-math, it should imply some behavior similar to this pragma being on.
This bug is different from PR34678 because not everything from this pragma
needs to be implemented, just a subset of the "when a program might [...] run
under non-default floating-point control modes." part. This seems to be the
whole purpose of this option.

Note also that https://gcc.gnu.org/wiki/FloatingPointMath doesn't mention a
limitation for traps (only for the change of the rounding mode).

For the reference, the current documentation:

  -fno-trapping-math

    Compile code assuming that floating-point operations cannot generate
user-visible traps. These traps include division by zero, overflow, underflow,
inexact result and invalid operation. This option requires that
-fno-signaling-nans be in effect. Setting this option may allow faster code if
one relies on “non-stop” IEEE arithmetic, for example.

    This option should never be turned on by any -O option since it can result
in incorrect output for programs that depend on an exact implementation of IEEE
or ISO rules/specifications for math functions.

    The default is -ftrapping-math.

(from https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html).

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Additional surprising behavior...

On the following C code:

void g (void);
double f (void)
{
  double x = 0.0, y = 0.0;
  double r = x / y;
  g ();
  return r;
}

one can see with -ftrapping-math (the default) that a 0.0 / 0.0 is done before
the call to g, which is the expected behavior (this time, the order of the
operations has been preserved):

        pxor    %xmm0, %xmm0
        divsd   %xmm0, %xmm0
        movsd   %xmm0, 8(%rsp)
        call    g@PLT
        movsd   8(%rsp), %xmm0

(note that with -fno-trapping-math, a NaN is just generated at compile time).

But on the following C code:

void g (void);
double f (void)
{
  double x = 1.0, y = 3.0;
  double r = x / y;
  g ();
  return r;
}

GCC behaves as with -fno-trapping-math, i.e. g is called, then the rounded
value of 1/3 is returned, while there should have been an inexact exception
(the GCC manual explicitly mentions inexact as one of the possible traps).

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Mon, 30 Aug 2021, vincent-gcc at vinc17 dot net via Gcc-bugs wrote:

> In the generated code with -O1 and above, one can see that the multiplication
> is done after g is called, even if -ftrapping-math is used (which is the
> default). This is incorrect as x * 5.0 may trap, terminating the program with a
> floating-point exception, in which case g must not be executed.

It's incorrect as the function g might call fetestexcept and examine the 
floating-point exception flags raised, or feclearexcept to clear them.  
That has nothing to do with trap enablement.  Since trap enablement is 
outside the scope of ISO C, and since various processors implement aspects 
of it differently making it inherently unportable, issues that appear 
without involving enabled traps are best considered without involving such 
traps at all.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
Implementation details about trap enablement is outside the scope of ISO C, but
the existence of traps is explicitly allowed by Annex F (when supported). F.8
says: "It includes also IEC 60559 dynamic rounding precision and trap
enablement modes, if the implementation supports them."

Note that Glibc provides feenableexcept and fedisableexcept to enable and
disable traps, and GCC should not ignore this possibility.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-08-31
           Keywords|                            |wrong-code
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase in the description it's TER that causes code motion of the
possibly trapping expression.  ssa_is_replaceable_p already tests
stmt_could_throw_p (that's including externally throwing) but fails to check
for traps.  In principle code motion would need to be restricted only up to
the next stmt that possibly terminates and only if we are supposed to preserve
(the order of) traps and external throwing stmts (with respect to possible
observers).

The question is whether it is important to preserve as much TER as possible
(for optimization purposes).  If that's not the case then the following fixes
this bug.

diff --git a/gcc/tree-outof-ssa.c b/gcc/tree-outof-ssa.c
index 1a133a09177..484f401ce68 100644
--- a/gcc/tree-outof-ssa.c
+++ b/gcc/tree-outof-ssa.c
@@ -64,8 +64,10 @@ ssa_is_replaceable_p (gimple *stmt)
   if (!is_gimple_assign (stmt))
     return false;

-  /* If the statement may throw an exception, it cannot be replaced.  */
-  if (stmt_could_throw_p (cfun, stmt))
+  /* If the statement may throw an exception or it could trap,
+     it cannot be replaced.  */
+  if (stmt_could_throw_p (cfun, stmt)
+      || gimple_could_trap_p (stmt))
     return false;

   /* Punt if there is more than 1 def.  */

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, the stmt_could_throw_p check was added in response to PR33593 which looks
quite similar (but the testcase uses -fnon-call-exceptions).

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bootstrap & regtest reveals

FAIL: gcc.dg/pr63743.c scan-rtl-dump-times expand "Swap operands" 1
...
FAIL: gcc.target/i386/pr85667-10.c scan-assembler-times addsd[
\\t]*40\\\\(%rsp\\\\), .* 1
FAIL: gcc.target/i386/pr85667-8.c scan-assembler-times addss[
\\t]*40\\\\(%rsp\\\\), .* 1
FAIL: gcc.target/i386/pr96696.c scan-assembler-not \\ti?mull\\t

for the first adjusting the testcase is OK - without TER the desired
expansion order is achieved already (well, not in general though, but the
testcase is too weak to show this).

the pr85667 cases need investigation and the pr96696 case shows that we
fail to capture optimal expansions of things like (x/y)*y because they
rely on TER.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
All of the FAILs could be avoided when taking the position of the use into
account but that would require some more substantial adjustment of TER.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testing an alternative.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:5e57bacf6f3599efea7634470db84121641c80b0

commit r12-3248-g5e57bacf6f3599efea7634470db84121641c80b0
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Aug 31 09:13:20 2021 +0200

    middle-end/102129 - avoid TER of possibly trapping expressions

    The following avoids applying TER to possibly trapping expressions,
    preventing a trapping FP multiplication to be moved across a call
    that should not be executed.

    2021-08-31  Richard Biener  <rguenther@suse.de>

            PR middle-end/102129
            * tree-ssa-ter.c (find_replaceable_in_bb): Do not move
            possibly trapping expressions across calls.

[Bug middle-end/102129] -ftrapping-math is broken or badly documented

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
      Known to work|                            |12.0
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for GCC 12.