* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
@ 2021-08-30 15:00 ` vincent-gcc at vinc17 dot net
2021-08-30 19:49 ` joseph at codesourcery dot com
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2021-08-30 15:00 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
2021-08-30 15:00 ` [Bug middle-end/102129] " vincent-gcc at vinc17 dot net
@ 2021-08-30 19:49 ` joseph at codesourcery dot com
2021-08-31 0:37 ` vincent-gcc at vinc17 dot net
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: joseph at codesourcery dot com @ 2021-08-30 19:49 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
2021-08-30 15:00 ` [Bug middle-end/102129] " vincent-gcc at vinc17 dot net
2021-08-30 19:49 ` joseph at codesourcery dot com
@ 2021-08-31 0:37 ` vincent-gcc at vinc17 dot net
2021-08-31 7:12 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2021-08-31 0:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (2 preceding siblings ...)
2021-08-31 0:37 ` vincent-gcc at vinc17 dot net
@ 2021-08-31 7:12 ` rguenth at gcc dot gnu.org
2021-08-31 7:18 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 7:12 UTC (permalink / raw)
To: gcc-bugs
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. */
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (3 preceding siblings ...)
2021-08-31 7:12 ` rguenth at gcc dot gnu.org
@ 2021-08-31 7:18 ` rguenth at gcc dot gnu.org
2021-08-31 8:25 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 7:18 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (4 preceding siblings ...)
2021-08-31 7:18 ` rguenth at gcc dot gnu.org
@ 2021-08-31 8:25 ` rguenth at gcc dot gnu.org
2021-08-31 8:26 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 8:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (5 preceding siblings ...)
2021-08-31 8:25 ` rguenth at gcc dot gnu.org
@ 2021-08-31 8:26 ` rguenth at gcc dot gnu.org
2021-08-31 8:49 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 8:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (6 preceding siblings ...)
2021-08-31 8:26 ` rguenth at gcc dot gnu.org
@ 2021-08-31 8:49 ` rguenth at gcc dot gnu.org
2021-08-31 9:38 ` cvs-commit at gcc dot gnu.org
2021-08-31 9:38 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 8:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102129
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testing an alternative.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (7 preceding siblings ...)
2021-08-31 8:49 ` rguenth at gcc dot gnu.org
@ 2021-08-31 9:38 ` cvs-commit at gcc dot gnu.org
2021-08-31 9:38 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-31 9:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug middle-end/102129] -ftrapping-math is broken or badly documented
2021-08-30 14:32 [Bug middle-end/102129] New: -ftrapping-math is broken or badly documented vincent-gcc at vinc17 dot net
` (8 preceding siblings ...)
2021-08-31 9:38 ` cvs-commit at gcc dot gnu.org
@ 2021-08-31 9:38 ` rguenth at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-08-31 9:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 11+ messages in thread