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]

  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: link
Be 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).