public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Aldy Hernandez <aldyh@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r13-2334] Make frange selftests work on !HONOR_NANS systems.
Date: Thu,  1 Sep 2022 07:09:49 +0000 (GMT)	[thread overview]
Message-ID: <20220901070949.489DE3853558@sourceware.org> (raw)

https://gcc.gnu.org/g:bdfe0d1ce0aebdb68b77e2c04a0f45956c56b449

commit r13-2334-gbdfe0d1ce0aebdb68b77e2c04a0f45956c56b449
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Aug 31 14:31:12 2022 +0200

    Make frange selftests work on !HONOR_NANS systems.
    
    I'm just shuffling the FP self tests here, with no change to existing
    functionality.
    
    If we agree that explicit NANs in the source code with !HONOR_NANS
    should behave any differently, I'm happy to address whatever needs
    fixing, but for now I'd like to unblock the !HONOR_NANS build systems.
    
    I have added an adaptation of a test Jakub suggested we handle in the PR:
    
    void funk(int cond)
    {
      float x;
    
      if (cond)
        x = __builtin_nan ("");
      else
        x = 1.24;
    
      bar(x);
    }
    
    For !HONOR_NANS, the range for the PHI of x_1 is the union of 1.24 and
    NAN which is really 1.24 with a maybe NAN.  This reflects the IL-- the
    presence of the actual NAN.  However, VRP will propagate this because
    it sees the 1.24 and ignores the possibility of a NAN, per
    !HONOR_NANS.  IMO, this is correct.  OTOH, for HONOR_NANS the unknown
    NAN property keeps us from propagating the value.
    
    Is there a reason we don't warn for calls to __builtin_nan when
    !HONOR_NANS?  That makes no sense to me.
    
            PR tree-optimization/106785
    
    gcc/ChangeLog:
    
            * value-range.cc (range_tests_nan): Adjust tests for !HONOR_NANS.
            (range_tests_floats): Same.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.dg/tree-ssa/vrp-float-nan-1.c: New test.

Diff:
---
 gcc/testsuite/gcc.dg/tree-ssa/vrp-float-nan-1.c | 18 ++++++++++++++++++
 gcc/value-range.cc                              | 23 ++++++++++++++---------
 2 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-nan-1.c b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-nan-1.c
new file mode 100644
index 00000000000..126949b2b4c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vrp-float-nan-1.c
@@ -0,0 +1,18 @@
+// { dg-do compile }
+// { dg-options "-O2 -ffinite-math-only -fdump-tree-evrp" }
+
+void bar(float);
+
+void funk(int cond)
+{
+  float x;
+
+  if (cond)
+    x = __builtin_nan ("");
+  else
+    x = 1.24;
+
+  bar(x);
+}
+
+// { dg-final { scan-tree-dump-times "bar \\(1.24" 1 "evrp" } }
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 473139c6dbd..3c7d4cb84b9 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -3535,13 +3535,16 @@ range_tests_nan ()
   REAL_VALUE_TYPE q, r;
 
   // Equal ranges but with differing NAN bits are not equal.
-  r1 = frange_float ("10", "12");
-  r0 = r1;
-  ASSERT_EQ (r0, r1);
-  r0.set_nan (fp_prop::NO);
-  ASSERT_NE (r0, r1);
-  r0.set_nan (fp_prop::YES);
-  ASSERT_NE (r0, r1);
+  if (HONOR_NANS (float_type_node))
+    {
+      r1 = frange_float ("10", "12");
+      r0 = r1;
+      ASSERT_EQ (r0, r1);
+      r0.set_nan (fp_prop::NO);
+      ASSERT_NE (r0, r1);
+      r0.set_nan (fp_prop::YES);
+      ASSERT_NE (r0, r1);
+    }
 
   // NAN ranges are not equal to each other.
   r0 = frange_nan (float_type_node);
@@ -3624,9 +3627,11 @@ range_tests_floats ()
   if (HONOR_SIGNED_ZEROS (float_type_node))
     range_tests_signed_zeros ();
 
-  // A range of [-INF,+INF] is actually VARYING...
+  // A range of [-INF,+INF] is actually VARYING if no other properties
+  // are set.
   r0 = frange_float ("-Inf", "+Inf");
-  ASSERT_TRUE (r0.varying_p ());
+  if (r0.get_nan ().varying_p ())
+    ASSERT_TRUE (r0.varying_p ());
   // ...unless it has some special property...
   r0.set_nan (fp_prop::NO);
   ASSERT_FALSE (r0.varying_p ());

                 reply	other threads:[~2022-09-01  7:09 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220901070949.489DE3853558@sourceware.org \
    --to=aldyh@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).