[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #12 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:6ea5fb3cc7f3cc9b731d72183c66c23543876f5a commit r12-5529-g6ea5fb3cc7f3cc9b731d72183c66c23543876f5a Author: Roger Sayle Date: Thu Nov 25 19:02:06 2021 + PR middle-end/103406: Check for Inf before simplifying x-x. This is a simple one line fix to the regression PR middle-end/103406, where x - x is being folded to 0.0 even when x is +Inf or -Inf. In GCC 11 and previously, we'd check whether the type honored NaNs (which implicitly covered the case where the type honors infinities), but my patch to test whether the operand could potentially be NaN failed to also check whether the operand could potentially be Inf. 2021-11-25 Roger Sayle gcc/ChangeLog PR middle-end/103406 * match.pd (minus @0 @0): Check tree_expr_maybe_infinite_p. gcc/testsuite/ChangeLog PR middle-end/103406 * gcc.dg/pr103406.c: New test case.
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #11 from joseph at codesourcery dot com --- The sign of a NaN result is never specified in C except for fabs, copysign, negation, unary + (and assignment to the same format in the case where that's copy rather than convertFormat). The result should of course be NaN (of any sign), not 0. The reason soft-fp (and thus sfp-machine.h) has special support for choosing a NaN result based on NaN operands is because soft-fp is also used in the Linux kernel for emulating floating-point instructions, and in that context the aim is to follow the semantics of those instructions, which specifies things left unspecified in IEEE 754 and its C bindings. That isn't relevant at the level of C code or libgcc functions.
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #10 from Richard Biener --- But I'm not sure what the stance is on the sign of NaNs
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 --- Comment #9 from Richard Biener --- simplify_binary_operation_1 has /* ((-a) + b) -> (b - a) and similarly for (a + (-b)). These transformations are safe even for IEEE. */ if (GET_CODE (op0) == NEG) return simplify_gen_binary (MINUS, mode, op1, XEXP (op0, 0)); else if (GET_CODE (op1) == NEG) return simplify_gen_binary (MINUS, mode, op0, XEXP (op1, 0));
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #8 from Richard Biener ---
And the -nan vs. nan is because we fold x + -y to x - y:
/* We can't reassociate at all for saturating types. */
(if (!TYPE_SATURATING (type))
/* Contract negates. */
/* A + (-B) -> A - B */
(simplify
(plus:c @0 (convert? (negate @1)))
/* Apply STRIP_NOPS on the negate. */
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
&& !TYPE_OVERFLOW_SANITIZED (type))
(with
{
tree t1 = type;
if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_WRAPS (type) != TYPE_OVERFLOW_WRAPS (TREE_TYPE (@1)))
t1 = TYPE_OVERFLOW_WRAPS (type) ? type : TREE_TYPE (@1);
}
(convert (minus (convert:t1 @0) (convert:t1 @1))
all the negate contracting misses HONOR_SIGNED_ZEROS/HONOR_NANS checking?
Not sure if they are really a problem for signed zeros? If so we should
try to get a testcase for that as well.
diff --git a/gcc/match.pd b/gcc/match.pd
index 5adcd6bd02c..9cdd113e02c 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2471,7 +2473,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(plus:c @0 (convert? (negate @1)))
/* Apply STRIP_NOPS on the negate. */
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
- && !TYPE_OVERFLOW_SANITIZED (type))
+ && !TYPE_OVERFLOW_SANITIZED (type)
+ && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
(with
{
tree t1 = type;
@@ -2484,7 +2487,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(simplify
(minus @0 (convert? (negate @1)))
(if (tree_nop_conversion_p (type, TREE_TYPE (@1))
- && !TYPE_OVERFLOW_SANITIZED (type))
+ && !TYPE_OVERFLOW_SANITIZED (type)
+ && (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@1)))
(with
{
tree t1 = type;
btw, that doesn't fix it since combine will happily contract the negate as
well:
- 10: {r88:DF=-r83:DF;use r89:V2DF;clobber flags:CC;}
- REG_DEAD r89:V2DF
- REG_UNUSED flags:CC
- 11: r90:DF=r88:DF+r83:DF
- REG_DEAD r88:DF
+9: NOTE_INSN_DELETED
+ 10: NOTE_INSN_DELETED
+ 11: r90:DF=r83:DF-r83:DF
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
Status|NEW |ASSIGNED
--- Comment #7 from Roger Sayle ---
I'm currently bootstrapping and regression testing this fix:
(simplify
(minus @0 @0)
- (if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
+ (if (!FLOAT_TYPE_P (type)
+ || (!tree_expr_maybe_nan_p (@0)
+ && !tree_expr_maybe_infinite_p (@0)))
{ build_zero_cst (type); }))
[Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406 Richard Biener changed: What|Removed |Added Summary|gcc -O0 behaves differently |[12 Regression] gcc -O0 |on "DBL_MAX related |behaves differently on |operations" than gcc -O1|"DBL_MAX related |and above |operations" than gcc -O1 ||and above Component|c |middle-end Target Milestone|--- |12.0
