* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
@ 2021-11-24 11:21 ` pinskia at gcc dot gnu.org
2021-11-24 11:23 ` ubizjak at gmail dot com
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-24 11:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is interesting.
The trunk does 0.0 for both -O0 and -O1.
ICC also does 0.0 for both -O0 and -O1 and -0.0 for -O2.
clang does -nan for -O1, -O2 and -O0
MSVC does nan for /O2 and /O1 (7ff8000000000000) and for the non-optimizing
case (I think if I read the assembly correctly).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
2021-11-24 11:21 ` [Bug c/103406] " pinskia at gcc dot gnu.org
@ 2021-11-24 11:23 ` ubizjak at gmail dot com
2021-11-24 11:29 ` pinskia at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: ubizjak at gmail dot com @ 2021-11-24 11:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
gcc/libgcc/config/i386/sfp-machine.h says:
/* Here is something Intel misdesigned: the specs don't define
the case where we have two NaNs with same mantissas, but
different sign. Different operations pick up different NaNs. */
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
2021-11-24 11:21 ` [Bug c/103406] " pinskia at gcc dot gnu.org
2021-11-24 11:23 ` ubizjak at gmail dot com
@ 2021-11-24 11:29 ` pinskia at gcc dot gnu.org
2021-11-24 11:54 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-24 11:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, the trunk is constant folding (maybe wrong?).
We used to get for 11.1.0:
_1 = 1.79769313486231570814527423731704356798070567525844996599e+308 *
2.0e+0;
_2 = 1.79769313486231570814527423731704356798070567525844996599e+308 *
2.0e+0;
_3 = _1 - _2;
x_6 = -_3;
But now we get 0.0.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (2 preceding siblings ...)
2021-11-24 11:29 ` pinskia at gcc dot gnu.org
@ 2021-11-24 11:54 ` rguenth at gcc dot gnu.org
2021-11-24 12:01 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 11:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords| |wrong-code
Last reconfirmed| |2021-11-24
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Already .original at -O0 has
double x = -0.0;
double y = 0.0;
double z = x + y;
printf ((const char * restrict) "%lf\n", z);
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (3 preceding siblings ...)
2021-11-24 11:54 ` rguenth at gcc dot gnu.org
@ 2021-11-24 12:01 ` rguenth at gcc dot gnu.org
2021-11-24 12:02 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 12:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
We are folding
(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0) -
(1.79769313486231570814527423731704356798070567525844996599e+308 * 2.0e+0)
to 0.0 via
(simplify
(minus @0 @0)
(if (!FLOAT_TYPE_P (type) || !tree_expr_maybe_nan_p (@0))
{ build_zero_cst (type); }))
but appearantly even Inf - Inf is not zero.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug c/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (4 preceding siblings ...)
2021-11-24 12:01 ` rguenth at gcc dot gnu.org
@ 2021-11-24 12:02 ` rguenth at gcc dot gnu.org
2021-11-24 12:03 ` [Bug middle-end/103406] [12 Regression] " rguenth at gcc dot gnu.org
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sayle at gcc dot gnu.org
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Caused by g:5b02ed4b8768 but latent before (we missed !HONOR_INFINITIES on the
pattern).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (5 preceding siblings ...)
2021-11-24 12:02 ` rguenth at gcc dot gnu.org
@ 2021-11-24 12:03 ` rguenth at gcc dot gnu.org
2021-11-24 12:29 ` roger at nextmovesoftware dot com
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 12:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Richard Biener <rguenth at gcc dot gnu.org> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (6 preceding siblings ...)
2021-11-24 12:03 ` [Bug middle-end/103406] [12 Regression] " rguenth at gcc dot gnu.org
@ 2021-11-24 12:29 ` roger at nextmovesoftware dot com
2021-11-24 13:02 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: roger at nextmovesoftware dot com @ 2021-11-24 12:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle <roger at nextmovesoftware dot com> 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 <roger at nextmovesoftware dot com> ---
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); }))
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (7 preceding siblings ...)
2021-11-24 12:29 ` roger at nextmovesoftware dot com
@ 2021-11-24 13:02 ` rguenth at gcc dot gnu.org
2021-11-24 13:04 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 13:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (8 preceding siblings ...)
2021-11-24 13:02 ` rguenth at gcc dot gnu.org
@ 2021-11-24 13:04 ` rguenth at gcc dot gnu.org
2021-11-24 13:05 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 13:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
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));
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (9 preceding siblings ...)
2021-11-24 13:04 ` rguenth at gcc dot gnu.org
@ 2021-11-24 13:05 ` rguenth at gcc dot gnu.org
2021-11-24 22:22 ` joseph at codesourcery dot com
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-11-24 13:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
But I'm not sure what the stance is on the sign of NaNs
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (10 preceding siblings ...)
2021-11-24 13:05 ` rguenth at gcc dot gnu.org
@ 2021-11-24 22:22 ` joseph at codesourcery dot com
2021-11-25 19:04 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: joseph at codesourcery dot com @ 2021-11-24 22:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #11 from joseph at codesourcery dot com <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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] [12 Regression] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (11 preceding siblings ...)
2021-11-24 22:22 ` joseph at codesourcery dot com
@ 2021-11-25 19:04 ` cvs-commit at gcc dot gnu.org
2021-11-25 19:40 ` [Bug middle-end/103406] " roger at nextmovesoftware dot com
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-25 19:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Roger Sayle <sayle@gcc.gnu.org>:
https://gcc.gnu.org/g:6ea5fb3cc7f3cc9b731d72183c66c23543876f5a
commit r12-5529-g6ea5fb3cc7f3cc9b731d72183c66c23543876f5a
Author: Roger Sayle <roger@nextmovesoftware.com>
Date: Thu Nov 25 19:02:06 2021 +0000
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 <roger@nextmovesoftware.com>
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (12 preceding siblings ...)
2021-11-25 19:04 ` cvs-commit at gcc dot gnu.org
@ 2021-11-25 19:40 ` roger at nextmovesoftware dot com
2021-11-25 20:29 ` joseph at codesourcery dot com
2021-11-26 17:58 ` roger at nextmovesoftware dot com
15 siblings, 0 replies; 17+ messages in thread
From: roger at nextmovesoftware dot com @ 2021-11-25 19:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|roger at nextmovesoftware dot com |unassigned at gcc dot gnu.org
Summary|[12 Regression] gcc -O0 |gcc -O0 behaves differently
|behaves differently on |on "DBL_MAX related
|"DBL_MAX related |operations" than gcc -O1
|operations" than gcc -O1 |and above
|and above |
Target| |x86_64
--- Comment #13 from Roger Sayle <roger at nextmovesoftware dot com> ---
The Inf - Inf => 0.0 regression should now be fixed on mainline.
Hmm. As hinted by Richard Beiner's investigation, the underlying problem is
even more pervasive. It turns out that on x86/IA64 chips, floating point
addition is not commutative, i.e. x+y is not the same as y+x, as demonstrated
by the test program below:
#include <stdio.h>
const double pn = __builtin_nan("");
const double mn = -__builtin_nan("");
__attribute__ ((noinline, noclone))
double plus(double x, double y)
{
return x + y;
}
int main()
{
printf("%lf\n",plus(pn,mn));
printf("%lf\n",plus(mn,pn));
return 0;
}
Output:
nan
-nan
Unfortunately, GCC assumes almost everywhere the FP addition is commutative
and (as per comments #8 and #9) associative with negation/minus. This appears
to be target property, c.f. libgcc's _FP_CHOOSENAN, but could in theory be
resolved by a -fstrict-math mode (that implies -ftrapping-math) that disables
commutativity (swapping of operands) throughout the compiler, including
reload/fold-const etc., on affected Intel-like targets.
Perhaps this PR is a duplicate now that the regression has been fixed?
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (13 preceding siblings ...)
2021-11-25 19:40 ` [Bug middle-end/103406] " roger at nextmovesoftware dot com
@ 2021-11-25 20:29 ` joseph at codesourcery dot com
2021-11-26 17:58 ` roger at nextmovesoftware dot com
15 siblings, 0 replies; 17+ messages in thread
From: joseph at codesourcery dot com @ 2021-11-25 20:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #14 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
There is no reasonable definition of how operands of binary + map to
particular operands of a particular instruction and so no -f or -m option
could sensibly be defined for that. When the result is a NaN, there is no
requirement at all on what (quiet) NaN it is (beyond a preference for
preservation of the payload of a NaN operand if there is at least one NaN
operand).
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug middle-end/103406] gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above
2021-11-24 11:09 [Bug c/103406] New: gcc -O0 behaves differently on "DBL_MAX related operations" than gcc -O1 and above shaohua.li at inf dot ethz.ch
` (14 preceding siblings ...)
2021-11-25 20:29 ` joseph at codesourcery dot com
@ 2021-11-26 17:58 ` roger at nextmovesoftware dot com
15 siblings, 0 replies; 17+ messages in thread
From: roger at nextmovesoftware dot com @ 2021-11-26 17:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #15 from Roger Sayle <roger at nextmovesoftware dot com> ---
I believe this is (now) a duplicate of PR target/45365.
*** This bug has been marked as a duplicate of bug 45365 ***
^ permalink raw reply [flat|nested] 17+ messages in thread