From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B8DB53858D35; Thu, 20 Jan 2022 07:22:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B8DB53858D35 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure Date: Thu, 20 Jan 2022 07:22:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: build, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 07:22:42 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103121 --- Comment #23 from rguenther at suse dot de --- On Wed, 19 Jan 2022, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103121 >=20 > --- Comment #22 from Andrew Macleod --- > (In reply to rguenther@suse.de from comment #21) > > On Tue, 18 Jan 2022, amacleod at redhat dot com wrote: > >=20 > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103121 > > >=20 > > > --- Comment #20 from Andrew Macleod --- > > > 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 1= 5..=20 > > >=20 > > > So I do not know where this stands, I don't think ranger is even invo= lved? > >=20 > > 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. > >=20 > > 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). > >=20 > > 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). >=20 > The EVRP implementation of range_of_expr() might be able to verify that t= he > context is correct at the time of the call and trap. I'll have a look.=20 >=20 > I'm not convinced that is whats at play here tho. Unless new code was add= ed to > the pass to use ranger and it's API without actually converting it to ran= ger? Well, I don't see where EVRP ever had range_of_expr (), so that's clearly a ranger API and thus if the pass is using that and passing in a context that is asking for trouble. But from a quick look we're only passing down the stmt we're currently analyzing and ultimatively process via strlen_pass::before_dom_children. Unless pointer-query.cc somehow changes 'stmt' or does caching based on only SSA names, not including the 'stmt' context they were produced. Indeed the cache is populated with put_ref which doesn't have any 'stmt' context but an SSA name only. Martin? It seems some queries computing the cached size use the 'stmt' context of the _use_ but the cache is for definition points?=