public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure Date: Mon, 08 Nov 2021 19:36:59 +0000 [thread overview] Message-ID: <bug-103121-4-83kAZmfO9w@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103121-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121 Andrew Macleod <amacleod at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |amacleod at redhat dot com --- Comment #7 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Martin Sebor from comment #5) > I can reproduce the warning. It triggers for the store to *_23 in BB 13 > below (dumped by debug_ranger()), where _23 is the result of the alloca() > call in BB 4 plus some offset. In BB 4, ranger sees two ranges for the > alloca argument _4: [0, 0][2, +INF] on the edge 4->16, and [1, 1] on 4->12. > 4->12 dead-ends in BB 14 with a call to fancy_abort(), so the edge that > leads to BB 13 is 4->16. But when we ask in BB 4 for _4's range we get > VR_RANGE [1, 1]. That doesn't seem right. Without any guidance as to which > edge I'm interested in I'd expect to either get the union of the two ranges, > [0, +INF]. > BB4 doesn't "see" 2 ranges for _4. It calculates _4 as varying, since _1 is varying. You see at the bottom it shows what the value of _4 is on each outgoing edge.. its [1,1] on edge 4->12 and [0,0][2, +INF] on edge 4->16. so if you ask for the range of _4 in any block dominated by one of those edges you will see the appropriate range. Where are you getting VR_RANGE [1,1] from? If you ask for range_of_expr (r, _4, alloca_stmt) You should be getting varying. Thats all it knows at that point. Im not sure what you mean by "without any guidance as to which edge"? Either you are asking for the range on an edge, or on a stmt. If you ask for the range of _4 somewhere in BB13, you should be seeing unsigned int [0, 0][2, +INF] since thats the value out 4->16 that eventually reaches BB13. > =========== BB 4 ============ > Imports: _1 > Exports: _1 > _1 unsigned int VARYING > Equivalence set : [_1, _2] > Relational : (_4 != _1) > <bb 4> [local count: 118111600]: > _4 = _1 + 1; > grp_name_37 = __builtin_alloca (_4); > p_38 = _32->identifier.id.str; > q_39 = _35->identifier.id.str; > if (_1 != 0) > goto <bb 16>; [89.00%] > else > goto <bb 12>; [11.00%] > > grp_name_37 : char * [1B, +INF] > 4->16 (T) _1 : unsigned int [1, +INF] > 4->16 (T) _4 : unsigned int [0, 0][2, +INF] > 4->12 (F) _1 : unsigned int [0, 0] > 4->12 (F) _4 : unsigned int [1, 1] > > =========== BB 13 ============ > Imports: diff_seen_24 > Exports: diff_seen_24 > diff_seen_24 bool VARYING > idx_47 size_t [1, +INF] > Relational : (_22 <= idx_47) > <bb 13> [local count: 105119324]: > _23 = grp_name_37 + idx_47; > *_23 = 0; > if (diff_seen_24 != 0) > goto <bb 15>; [100.00%] > else > goto <bb 14>; [0.00%] > > _23 : char * [1B, +INF] > 13->14 (F) diff_seen_24 : bool [0, 0] > 13->15 (T) diff_seen_24 : bool [1, 1]
next prev parent reply other threads:[~2021-11-08 19:36 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-11-07 22:33 [Bug other/103121] New: Warnings danglin at gcc dot gnu.org 2021-11-08 8:19 ` [Bug other/103121] [12 Regression] Warnings in cp/optimize.c causing build failure pinskia at gcc dot gnu.org 2021-11-08 9:24 ` [Bug tree-optimization/103121] " rguenth at gcc dot gnu.org 2021-11-08 13:19 ` dave.anglin at bell dot net 2021-11-08 16:08 ` msebor at gcc dot gnu.org 2021-11-08 16:19 ` danglin at gcc dot gnu.org 2021-11-08 19:00 ` msebor at gcc dot gnu.org 2021-11-08 19:04 ` msebor at gcc dot gnu.org 2021-11-08 19:36 ` amacleod at redhat dot com [this message] 2021-11-08 19:50 ` msebor at gcc dot gnu.org 2021-11-08 20:07 ` amacleod at redhat dot com 2021-11-08 20:48 ` msebor at gcc dot gnu.org 2021-11-08 21:11 ` amacleod at redhat dot com 2021-11-08 21:48 ` msebor at gcc dot gnu.org 2021-11-08 22:35 ` msebor at gcc dot gnu.org 2021-11-09 0:01 ` amacleod at redhat dot com 2021-11-09 1:11 ` msebor at gcc dot gnu.org 2021-11-09 7:20 ` aldyh at gcc dot gnu.org 2021-11-09 7:24 ` aldyh at gcc dot gnu.org 2021-11-09 8:22 ` rguenth at gcc dot gnu.org 2022-01-18 14:34 ` rguenth at gcc dot gnu.org 2022-01-18 20:18 ` amacleod at redhat dot com 2022-01-19 7:36 ` rguenther at suse dot de 2022-01-19 17:50 ` amacleod at redhat dot com 2022-01-20 7:22 ` rguenther at suse dot de 2022-01-20 7:25 ` rguenth at gcc dot gnu.org 2022-01-20 15:49 ` amacleod at redhat dot com 2022-01-20 16:14 ` msebor at gcc dot gnu.org 2022-01-20 17:14 ` danglin at gcc dot gnu.org 2022-01-21 7:27 ` rguenther at suse dot de 2022-01-21 16:16 ` msebor at gcc dot gnu.org 2022-01-21 17:53 ` amacleod at redhat dot com 2022-01-21 18:59 ` msebor 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-103121-4-83kAZmfO9w@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).