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-2394] Do not clobber signbit when unioning a NAN. Date: Sun, 4 Sep 2022 16:18:32 +0000 (GMT) [thread overview] Message-ID: <20220904161832.03CD23856090@sourceware.org> (raw) https://gcc.gnu.org/g:8293a9632c46c8f3f9d531c09194aa8738944927 commit r13-2394-g8293a9632c46c8f3f9d531c09194aa8738944927 Author: Aldy Hernandez <aldyh@redhat.com> Date: Sun Sep 4 08:00:02 2022 +0200 Do not clobber signbit when unioning a NAN. When unioning a known NAN and something else, we're dropping the properties of the NAN, particularly the sign. This fixes the oversight. With this patch, we should be keeping the sign bit up to date, even in the presence of NANs. gcc/ChangeLog: * value-range.cc (frange::union_): Do not drop properties when unioning a NAN with something else. (range_tests_signed_zeros): Add tests. Diff: --- gcc/value-range.cc | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index a1c29f7bd0b..c9f42fe272c 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -475,19 +475,25 @@ frange::union_ (const vrange &v) return true; } - // If one side has a NAN, the union is just the other side plus the - // NAN bit. + // If one side has a NAN, the union is the other side, plus the union + // of the properties and the possibility of a NAN. if (get_nan ().yes_p ()) { + frange_props save = m_props; *this = r; - // NOP if NAN already set. + m_props = save; + m_props.union_ (r.m_props); set_nan (fp_prop::VARYING); + if (flag_checking) + verify_range (); return true; } if (r.get_nan ().yes_p ()) { - // NOP if NAN already set. + m_props.union_ (r.m_props); set_nan (fp_prop::VARYING); + if (flag_checking) + verify_range (); return true; } @@ -3676,6 +3682,7 @@ range_tests_signed_zeros () { tree zero = build_zero_cst (float_type_node); tree neg_zero = fold_build1 (NEGATE_EXPR, float_type_node, zero); + REAL_VALUE_TYPE q, r; frange r0, r1; // Since -0.0 == +0.0, a range of [-0.0, -0.0] should contain +0.0 @@ -3711,6 +3718,16 @@ range_tests_signed_zeros () r1.set_signbit (fp_prop::YES); r0.union_ (r1); ASSERT_TRUE (r0.zero_p () && r0.get_signbit ().varying_p ()); + + // NAN U [5,6] should be [5,6] with no sign info. + r0 = frange_nan (float_type_node); + r1 = frange_float ("5", "6"); + r0.union_ (r1); + real_from_string (&q, "5"); + real_from_string (&r, "6"); + ASSERT_TRUE (real_identical (&q, &r0.lower_bound ())); + ASSERT_TRUE (real_identical (&r, &r0.upper_bound ())); + ASSERT_TRUE (r0.get_signbit ().varying_p ()); } static void
reply other threads:[~2022-09-04 16:18 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=20220904161832.03CD23856090@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: linkBe 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).