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: Wed, 19 Jan 2022 17:50:46 +0000 [thread overview]
Message-ID: <bug-103121-4-FpwlHscFqt@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
--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #21)
> On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> >
> > --- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
> > I think the anaylsis in comment 5 and onward needs to be redone since it was
> > using rangers debug output to see something wrong, but the pass isn't even
> > using ranger.. It is using EVRP as we determined in comments 14 and 15..
> >
> > So I do not know where this stands, I don't think ranger is even involved?
>
> The ranger API is, which gives the caller the possibility to pass in
> a "context" stmt. But with EVRP you can only ever query the "actual"
> context (the BB the domwalk currently is processing), since global
> ranges are adjusted. If you ever ask for a different context you
> will get wrong answers.
>
> So maybe the ranger API needs to be adjusted to ICE whenever the context
> is not the current one in case EVRP is active (not sure if it even knows
> about the EVRP domwalk).
>
> Or using the ranger APIs should be forbidden when the EVRP domwalk is
> active (or the EVRP domwalk needs to be instructed to not adjust
> global ranges - IIRC we had a switch for that somewhere).
The EVRP implementation of range_of_expr() might be able to verify that the
context is correct at the time of the call and trap. I'll have a look.
I'm not convinced that is whats at play here tho. Unless new code was added to
the pass to use ranger and it's API without actually converting it to ranger?
next prev parent reply other threads:[~2022-01-19 17:50 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
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 [this message]
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-FpwlHscFqt@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).