From: Aldy Hernandez Date: Tue, 19 Mar 2024 15:35:41 +0000 (+0100) Subject: Verify that reading back from vrange_storage doesn't drop bits. X-Git-Tag: basepoints/gcc-16~9519 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=92f74ee21218cab08d7bb7769004a65e8a291fa3;p=thirdparty%2Fgcc.git Verify that reading back from vrange_storage doesn't drop bits. 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. --- diff --git a/gcc/value-range-storage.cc b/gcc/value-range-storage.cc index f00474ad0e6..09a29776a0e 100644 --- a/gcc/value-range-storage.cc +++ b/gcc/value-range-storage.cc @@ -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 (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