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-5696] irange: Compare nonzero bits in irange with widest_int [PR108639] Date: Fri, 3 Feb 2023 20:33:36 +0000 (GMT) [thread overview] Message-ID: <20230203203336.4991F3858C52@sourceware.org> (raw) https://gcc.gnu.org/g:e261fcefb71e1270673f0457fcc73711f13d3079 commit r13-5696-ge261fcefb71e1270673f0457fcc73711f13d3079 Author: Aldy Hernandez <aldyh@redhat.com> Date: Thu Feb 2 18:08:44 2023 +0100 irange: Compare nonzero bits in irange with widest_int [PR108639] The problem here is we are trying to compare two ranges with different precisions and the == operator in wide_int is complaining. Interestingly, the problem is not the nonzero bits, but the fact that the entire ranges have different precisions. The reason we don't ICE when comparing the sub-ranges, is because the code in irange::operator== works on trees, and tree_int_cst_equal is promoting the comparison to a widest int: if (TREE_CODE (t1) == INTEGER_CST && TREE_CODE (t2) == INTEGER_CST && wi::to_widest (t1) == wi::to_widest (t2)) return 1; This is why we don't see the ICE until the nonzero bits comparison is done on wide ints. I think we should maintain the current equality behavior, and follow suit in the nonzero bit comparison. I have also fixed the legacy equality code, even though technically nonzero bits shouldn't appear in legacy. But better safe than sorry. PR tree-optimization/108639 gcc/ChangeLog: * value-range.cc (irange::legacy_equal_p): Compare nonzero bits as widest_int. (irange::operator==): Same. Diff: --- gcc/testsuite/gcc.c-torture/compile/pr108638.c | 12 ++++++++++++ gcc/testsuite/gcc.c-torture/compile/pr108639.c | 11 +++++++++++ gcc/value-range.cc | 11 +++++++++-- 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/gcc/testsuite/gcc.c-torture/compile/pr108638.c b/gcc/testsuite/gcc.c-torture/compile/pr108638.c new file mode 100644 index 00000000000..755c151a09a --- /dev/null +++ b/gcc/testsuite/gcc.c-torture/compile/pr108638.c @@ -0,0 +1,12 @@ +/* PR tree-optimization/108638 */ + +long long a; +int b; + +void +foo (void) +{ + for (a = 0; a < __SIZEOF_LONG_LONG__ * __CHAR_BIT__; a++) + if (b) + b |= a << a; +} diff --git a/gcc/testsuite/gcc.c-torture/compile/pr108639.c b/gcc/testsuite/gcc.c-torture/compile/pr108639.c new file mode 100644 index 00000000000..ed826cc2f5a --- /dev/null +++ b/gcc/testsuite/gcc.c-torture/compile/pr108639.c @@ -0,0 +1,11 @@ +/* PR tree-optimization/108639 */ + +long long a; + +int +main () +{ + a = a ? 0 || 0 % 0 : 0; + a = a << a; + return 0; +} diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 26f6f26b01a..a535337c47a 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -1259,7 +1259,10 @@ irange::legacy_equal_p (const irange &other) const other.tree_lower_bound (0)) && vrp_operand_equal_p (tree_upper_bound (0), other.tree_upper_bound (0)) - && get_nonzero_bits () == other.get_nonzero_bits ()); + && (widest_int::from (get_nonzero_bits (), + TYPE_SIGN (type ())) + == widest_int::from (other.get_nonzero_bits (), + TYPE_SIGN (other.type ())))); } bool @@ -1294,7 +1297,11 @@ irange::operator== (const irange &other) const || !operand_equal_p (ub, ub_other, 0)) return false; } - return get_nonzero_bits () == other.get_nonzero_bits (); + widest_int nz1 = widest_int::from (get_nonzero_bits (), + TYPE_SIGN (type ())); + widest_int nz2 = widest_int::from (other.get_nonzero_bits (), + TYPE_SIGN (other.type ())); + return nz1 == nz2; } /* Return TRUE if this is a symbolic range. */
reply other threads:[~2023-02-03 20:33 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=20230203203336.4991F3858C52@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).