public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation Date: Wed, 02 Feb 2022 12:06:18 +0000 [thread overview] Message-ID: <bug-104334-4-naDa8XPakf@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104334-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrs at gcc dot gnu.org, | |rguenth at gcc dot gnu.org, | |rsandifo at gcc dot gnu.org --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- The difference might be in: 1938 /* Optimize comparisons with constants. */ 1939 if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0)) 1940 return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT) yi.val[0]; 1941 if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0)) 1942 return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT) xi.val[0]; 1943 /* Optimize the case of two HWIs. The HWIs are implicitly sign-extended 1944 for precisions greater than HOST_BITS_WIDE_INT, but sign-extending both 1945 values does not change the result. */ 1946 if (__builtin_expect (xi.len + yi.len == 2, true)) 1947 { 1948 unsigned HOST_WIDE_INT xl = xi.to_uhwi (); 1949 unsigned HOST_WIDE_INT yl = yi.to_uhwi (); 1950 return xl < yl; 1951 } Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while without LTO it is false. I'll verify that. Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4 and yi.to_uhwi () is 0. So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it is false, it will return 3 < 0. Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls invalid if 4 is not representable in type, or does the STATIC_CONSTANT_P case need to also check precision, or mask Xi.val[0]? And another question is, the 2, 3, 4 cases handling seems like an optimization, so wi_fold at line 192 should give the right answer, but it doesn't.
next prev parent reply other threads:[~2022-02-02 12:06 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-01 20:35 [Bug tree-optimization/104334] New: " jakub at gcc dot gnu.org 2022-02-01 20:35 ` [Bug tree-optimization/104334] [12 Regression] " jakub at gcc dot gnu.org 2022-02-01 20:48 ` jakub at gcc dot gnu.org 2022-02-02 1:27 ` pinskia at gcc dot gnu.org 2022-02-02 10:18 ` marxin at gcc dot gnu.org 2022-02-02 10:19 ` marxin at gcc dot gnu.org 2022-02-02 10:29 ` pinskia at gcc dot gnu.org 2022-02-02 10:37 ` jakub at gcc dot gnu.org 2022-02-02 12:06 ` jakub at gcc dot gnu.org [this message] 2022-02-02 12:13 ` jakub at gcc dot gnu.org 2022-02-02 12:26 ` rsandifo at gcc dot gnu.org 2022-02-02 12:30 ` rguenther at suse dot de 2022-02-02 12:31 ` jakub at gcc dot gnu.org 2022-02-02 12:38 ` [Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e marxin at gcc dot gnu.org 2022-02-02 12:46 ` jakub at gcc dot gnu.org 2022-02-02 12:51 ` marxin at gcc dot gnu.org 2022-02-02 13:39 ` jakub at gcc dot gnu.org 2022-02-02 13:50 ` amacleod at redhat dot com 2022-02-02 13:56 ` rguenther at suse dot de 2022-02-02 14:00 ` jakub at gcc dot gnu.org 2022-02-02 14:12 ` jakub at gcc dot gnu.org 2022-02-02 15:07 ` rsandifo at gcc dot gnu.org 2022-02-03 8:46 ` cvs-commit at gcc dot gnu.org 2022-02-03 8:46 ` jakub at gcc dot gnu.org
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=bug-104334-4-naDa8XPakf@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).