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/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f Date: Thu, 01 Dec 2022 16:52:38 +0000 [thread overview] Message-ID: <bug-107833-4-GmweDAKclP@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-107833-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833 --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I think this is CCP's fault rather than VRP. Everything I've looked at in the vrp2 dump looks right to me. In the outer loop, h/i is # RANGE [irange] int [0, 3] NONZERO 0x3 # h_41 = PHI <h_21(8), 0(2)> # i_44 = PHI <i_43(8), i_19(D)(2)> and the second inner loop has _13 = (unsigned int) i_44; // This is before the second inner loop ... <bb 6> [local count: 304150043]: # i_42 = PHI <i_23(7), i_44(5)> _50 = (unsigned int) i_42; _17 = -_50; _34 = _13 - _50; # RANGE [irange] int [0, 2] NONZERO 0x3 h_40 = (int) _34; where i_23 = i_42 + -1; and # h_21 = PHI <h_40(6), 3(7)> Now, sure, i is uninitialized (the i_19(D) in PHI of the outer loop), but as has been discussed in the first loop a < h isn't true and so we don't use i there, and in the second loop d isn't NULL and so we don't i-- there either, but due to the function call we must reread the d value after each iteration. Which is the reason for the h_40 = (int) ((unsigned) i_44 - i_42) computation to get h when d is non-NULL in some iteration - if d is always NULL, it would be 3 in the PHI. But ccp4 goes wild on this, Visiting PHI node: i_44 = PHI <i_43(8), i_19(D)(2)> Argument #0 (8 -> 3 not executable) Argument #1 (2 -> 3 executable) i_19(D) Value: UNDEFINED PHI node value: UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: _13 = (unsigned int) i_44; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: _50 = (unsigned int) i_42; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. ... Visiting statement: # RANGE [irange] int [0, 2] NONZERO 0x3 h_40 = (int) _34; which is likely UNDEFINED Lattice value changed to UNDEFINED. Adding SSA edges to worklist. etc., everything based on i is UNDEFINED. So, either our UNDEFINED handlingin CCP is incorrect, or we need to avoid creating that h_40 = (int) ((unsigned) i_44 - i_42) stuff in IVOPTS if it is based on uninitialized (but then, can't we get an uninitialized value propagated to it only after IVOPTS?).
next prev parent reply other threads:[~2022-12-01 16:52 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-23 12:48 [Bug tree-optimization/107833] New: wrong code at -Os and above on x86_64-linux-gnu zhendong.su at inf dot ethz.ch 2022-11-23 13:14 ` [Bug tree-optimization/107833] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f marxin at gcc dot gnu.org 2022-11-23 14:12 ` aldyh at gcc dot gnu.org 2022-11-23 14:17 ` marxin at gcc dot gnu.org 2022-11-23 15:07 ` aldyh at gcc dot gnu.org 2022-11-23 19:22 ` marxin at gcc dot gnu.org 2022-11-23 20:56 ` [Bug tree-optimization/107833] [12/13 Regression] " rguenth at gcc dot gnu.org 2022-12-01 16:14 ` jakub at gcc dot gnu.org 2022-12-01 16:52 ` jakub at gcc dot gnu.org [this message] 2022-12-01 17:32 ` jakub at gcc dot gnu.org 2022-12-01 19:54 ` pinskia at gcc dot gnu.org 2022-12-02 8:19 ` rguenth at gcc dot gnu.org 2022-12-02 10:16 ` jakub at gcc dot gnu.org 2022-12-02 13:24 ` rguenther at suse dot de 2022-12-02 13:55 ` rguenth at gcc dot gnu.org 2022-12-05 9:32 ` cvs-commit at gcc dot gnu.org 2022-12-12 11:20 ` [Bug tree-optimization/107833] [12 " cvs-commit at gcc dot gnu.org 2022-12-12 11:22 ` rguenth 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-107833-4-GmweDAKclP@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).