public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]
@ 2023-07-24 16:01 Jakub Jelinek
  2023-07-24 19:39 ` Joseph Myers
  2023-07-25 19:15 ` Aldy Hernandez
  0 siblings, 2 replies; 4+ messages in thread
From: Jakub Jelinek @ 2023-07-24 16:01 UTC (permalink / raw)
  To: Aldy Hernandez, Andrew MacLeod; +Cc: gcc-patches

Hi!

IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
but rounding towards negative infinity, in which case the result is -0
for all finite x.  x + x and x - (-x) if it is zero retain sign of x.
Now, range_arithmetic implements the normal rounds to even rounding,
and as the addition or subtraction in those cases is exact, we don't do any
further rounding etc. and e.g. on the testcase below distilled from glibc
compute a range [+0, +INF], which is fine for -fno-rounding-math or
if we'd have a guarantee that those statements aren't executed with rounding
towards negative infinity.

I believe it is only +- which has this problematic behavior and I think
it is best to deal with it in frange_arithmetic; if we know -frounding-math
is on, it is x + (-x) or x - x and we are asked to round to negative
infinity (i.e. want low bound rather than high bound), change +0 result to
-0.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
after a while for 13.3?  I'm afraid rushing this so late into 13.2...

2023-07-24  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/110755
	* range-op-float.cc (frange_arithmetic): Change +0 result to -0
	for PLUS_EXPR or MINUS_EXPR if -frounding-math, inf is negative and
	it is exact op1 + (-op1) or op1 - op1.

	* gcc.dg/pr110755.c: New test.

--- gcc/range-op-float.cc.jj	2023-07-23 19:32:20.832434105 +0200
+++ gcc/range-op-float.cc	2023-07-24 09:41:26.231030258 +0200
@@ -324,6 +324,24 @@ frange_arithmetic (enum tree_code code,
   bool inexact = real_arithmetic (&value, code, &op1, &op2);
   real_convert (&result, mode, &value);
 
+  /* When rounding towards negative infinity, x + (-x) and
+     x - x is -0 rather than +0 real_arithmetic computes.
+     So, when we are looking for lower bound (inf is negative),
+     use -0 rather than +0.  */
+  if (flag_rounding_math
+      && (code == PLUS_EXPR || code == MINUS_EXPR)
+      && !inexact
+      && real_iszero (&result)
+      && !real_isneg (&result)
+      && real_isneg (&inf))
+    {
+      REAL_VALUE_TYPE op2a = op2;
+      if (code == PLUS_EXPR)
+	op2a.sign ^= 1;
+      if (real_isneg (&op1) == real_isneg (&op2a) && real_equal (&op1, &op2a))
+	result.sign = 1;
+    }
+
   // Be extra careful if there may be discrepancies between the
   // compile and runtime results.
   bool round = false;
--- gcc/testsuite/gcc.dg/pr110755.c.jj	2023-07-21 10:34:05.037251433 +0200
+++ gcc/testsuite/gcc.dg/pr110755.c	2023-07-21 10:35:10.986326816 +0200
@@ -0,0 +1,29 @@
+/* PR tree-optimization/110755 */
+/* { dg-do run } */
+/* { dg-require-effective-target fenv } */
+/* { dg-require-effective-target hard_float } */
+/* { dg-options "-O2 -frounding-math" } */
+
+#include <fenv.h>
+
+__attribute__((noipa)) float
+foo (float x)
+{ 
+  if (x > 0.0)
+    { 
+      x += 0x1p+23;
+      x -= 0x1p+23;
+      x = __builtin_fabsf (x);
+    }
+  return x;
+}
+
+int
+main ()
+{
+#ifdef FE_DOWNWARD
+  fesetround (FE_DOWNWARD);
+  if (__builtin_signbit (foo (0.5)))
+    __builtin_abort ();
+#endif
+}

	Jakub


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]
  2023-07-24 16:01 [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755] Jakub Jelinek
@ 2023-07-24 19:39 ` Joseph Myers
  2023-07-24 19:45   ` Jakub Jelinek
  2023-07-25 19:15 ` Aldy Hernandez
  1 sibling, 1 reply; 4+ messages in thread
From: Joseph Myers @ 2023-07-24 19:39 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Aldy Hernandez, Andrew MacLeod, gcc-patches

On Mon, 24 Jul 2023, Jakub Jelinek via Gcc-patches wrote:

> I believe it is only +- which has this problematic behavior and I think

fma has the same property (of rounding-mode-dependent exact results), but 
I think that's not relevant here?

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]
  2023-07-24 19:39 ` Joseph Myers
@ 2023-07-24 19:45   ` Jakub Jelinek
  0 siblings, 0 replies; 4+ messages in thread
From: Jakub Jelinek @ 2023-07-24 19:45 UTC (permalink / raw)
  To: Joseph Myers; +Cc: Aldy Hernandez, Andrew MacLeod, gcc-patches

On Mon, Jul 24, 2023 at 07:39:05PM +0000, Joseph Myers wrote:
> On Mon, 24 Jul 2023, Jakub Jelinek via Gcc-patches wrote:
> 
> > I believe it is only +- which has this problematic behavior and I think
> 
> fma has the same property (of rounding-mode-dependent exact results), but 
> I think that's not relevant here?

Indeed, real_arithmetics doesn't handle FMA* and I think the ranger doesn't
either as of now, if it would, it would likely use mpfr for that and indeed
would need to take this into account.

	Jakub


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755]
  2023-07-24 16:01 [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755] Jakub Jelinek
  2023-07-24 19:39 ` Joseph Myers
@ 2023-07-25 19:15 ` Aldy Hernandez
  1 sibling, 0 replies; 4+ messages in thread
From: Aldy Hernandez @ 2023-07-25 19:15 UTC (permalink / raw)
  To: Jakub Jelinek, Andrew MacLeod; +Cc: gcc-patches

The frange bits look fine to me, so if you feel confident in the math 
logic, go right ahead :).

Thanks.
Aldy

On 7/24/23 18:01, Jakub Jelinek wrote:
> Hi!
> 
> IEEE754 says that x + (-x) and x - x result in +0 in all rounding modes
> but rounding towards negative infinity, in which case the result is -0
> for all finite x.  x + x and x - (-x) if it is zero retain sign of x.
> Now, range_arithmetic implements the normal rounds to even rounding,
> and as the addition or subtraction in those cases is exact, we don't do any
> further rounding etc. and e.g. on the testcase below distilled from glibc
> compute a range [+0, +INF], which is fine for -fno-rounding-math or
> if we'd have a guarantee that those statements aren't executed with rounding
> towards negative infinity.
> 
> I believe it is only +- which has this problematic behavior and I think
> it is best to deal with it in frange_arithmetic; if we know -frounding-math
> is on, it is x + (-x) or x - x and we are asked to round to negative
> infinity (i.e. want low bound rather than high bound), change +0 result to
> -0.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and
> after a while for 13.3?  I'm afraid rushing this so late into 13.2...
> 
> 2023-07-24  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR tree-optimization/110755
> 	* range-op-float.cc (frange_arithmetic): Change +0 result to -0
> 	for PLUS_EXPR or MINUS_EXPR if -frounding-math, inf is negative and
> 	it is exact op1 + (-op1) or op1 - op1.
> 
> 	* gcc.dg/pr110755.c: New test.
> 
> --- gcc/range-op-float.cc.jj	2023-07-23 19:32:20.832434105 +0200
> +++ gcc/range-op-float.cc	2023-07-24 09:41:26.231030258 +0200
> @@ -324,6 +324,24 @@ frange_arithmetic (enum tree_code code,
>     bool inexact = real_arithmetic (&value, code, &op1, &op2);
>     real_convert (&result, mode, &value);
>   
> +  /* When rounding towards negative infinity, x + (-x) and
> +     x - x is -0 rather than +0 real_arithmetic computes.
> +     So, when we are looking for lower bound (inf is negative),
> +     use -0 rather than +0.  */
> +  if (flag_rounding_math
> +      && (code == PLUS_EXPR || code == MINUS_EXPR)
> +      && !inexact
> +      && real_iszero (&result)
> +      && !real_isneg (&result)
> +      && real_isneg (&inf))
> +    {
> +      REAL_VALUE_TYPE op2a = op2;
> +      if (code == PLUS_EXPR)
> +	op2a.sign ^= 1;
> +      if (real_isneg (&op1) == real_isneg (&op2a) && real_equal (&op1, &op2a))
> +	result.sign = 1;
> +    }
> +
>     // Be extra careful if there may be discrepancies between the
>     // compile and runtime results.
>     bool round = false;
> --- gcc/testsuite/gcc.dg/pr110755.c.jj	2023-07-21 10:34:05.037251433 +0200
> +++ gcc/testsuite/gcc.dg/pr110755.c	2023-07-21 10:35:10.986326816 +0200
> @@ -0,0 +1,29 @@
> +/* PR tree-optimization/110755 */
> +/* { dg-do run } */
> +/* { dg-require-effective-target fenv } */
> +/* { dg-require-effective-target hard_float } */
> +/* { dg-options "-O2 -frounding-math" } */
> +
> +#include <fenv.h>
> +
> +__attribute__((noipa)) float
> +foo (float x)
> +{
> +  if (x > 0.0)
> +    {
> +      x += 0x1p+23;
> +      x -= 0x1p+23;
> +      x = __builtin_fabsf (x);
> +    }
> +  return x;
> +}
> +
> +int
> +main ()
> +{
> +#ifdef FE_DOWNWARD
> +  fesetround (FE_DOWNWARD);
> +  if (__builtin_signbit (foo (0.5)))
> +    __builtin_abort ();
> +#endif
> +}
> 
> 	Jakub
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-07-25 19:15 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-24 16:01 [PATCH] range-op-float: Fix up -frounding-math frange_arithmetic +- handling [PR110755] Jakub Jelinek
2023-07-24 19:39 ` Joseph Myers
2023-07-24 19:45   ` Jakub Jelinek
2023-07-25 19:15 ` Aldy Hernandez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).