]> git.ipfire.org Git - thirdparty/gcc.git/commitdiff
Verify that reading back from vrange_storage doesn't drop bits.
authorAldy Hernandez <aldyh@redhat.com>
Tue, 19 Mar 2024 15:35:41 +0000 (16:35 +0100)
committerAldy Hernandez <aldyh@redhat.com>
Sun, 28 Apr 2024 19:03:00 +0000 (21:03 +0200)
We have a sanity check in the irange storage code to make sure that
reading back a cache entry we have just written to yields exactly the
same range.  There's no need to do this only for integers.  This patch
moves the code to a more generic place.

However, doing so tickles a latent bug in the frange code where a
range is being pessimized from [0.0, 1.0] to [-0.0, 1.0].  Exclude
checking frange's until this bug is fixed.

gcc/ChangeLog:

* value-range-storage.cc (irange_storage::set_irange): Move
verification code from here...
(vrange_storage::set_vrange): ...to here.

gcc/value-range-storage.cc

index f00474ad0e6d53fe8b3941b061a50571cc7bddb5..09a29776a0ee5806c34374220270cb1943b83760 100644 (file)
@@ -165,6 +165,19 @@ vrange_storage::set_vrange (const vrange &r)
     }
   else
     gcc_unreachable ();
+
+  // Verify that reading back from the cache didn't drop bits.
+  if (flag_checking
+      // FIXME: Avoid checking frange, as it currently pessimizes some ranges:
+      //
+      // gfortran.dg/pr49472.f90 pessimizes [0.0, 1.0] into [-0.0, 1.0].
+      && !is_a <frange> (r)
+      && !r.undefined_p ())
+    {
+      Value_Range tmp (r);
+      get_vrange (tmp, r.type ());
+      gcc_checking_assert (tmp == r);
+    }
 }
 
 // Restore R from storage.
@@ -306,13 +319,6 @@ irange_storage::set_irange (const irange &r)
   irange_bitmask bm = r.m_bitmask;
   write_wide_int (val, len, bm.value ());
   write_wide_int (val, len, bm.mask ());
-
-  if (flag_checking)
-    {
-      int_range_max tmp;
-      get_irange (tmp, r.type ());
-      gcc_checking_assert (tmp == r);
-    }
 }
 
 static inline void