From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 3CA613858D1E; Wed, 29 Mar 2023 13:35:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3CA613858D1E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680096901;
	bh=LzqqJD14jK9kgJkstaY6ZsQIGBIxAKUVzLEcu2t6QXk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=U0EYg9U2NNSN4L7r01X9KMiI2XHGsfJDnsaKEq+isnlHimbC8YS2klPJPqBWTC1eY
	 RRLi1b2Kf+icIzkFmlsginYFupWqPU7IwCTHW9UrPHF4x+ieQWlsKwGi1MwkL/vqoW
	 YS0SVwGCkZ8LTl3JhneT9U+GK0gmF00wSrg9f9ME=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: =?UTF-8?B?W0J1ZyBtaWRkbGUtZW5kLzEwNjAwOF0gWzExLzEyLzEzIFJlZ3Jl?=
 =?UTF-8?B?c3Npb25dIHdhcm5pbmc6IOKAmCgoKGNoYXIgKilsb2FkY21kcy4xMTNfNjgg?=
 =?UTF-8?B?KyBfOTMzICsgMTYpKVszMjk0MDYxNDQxNzMzODQ4NDldLm1hcGVuZOKAmSBt?=
 =?UTF-8?B?YXkgYmUgdXNlZCB1bmluaXRpYWxpemVkIFstV21heWJlLXVuaW5pdGlhbGl6?=
 =?UTF-8?B?ZWRd?=
Date: Wed, 29 Mar 2023 13:35:00 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 11.2.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: priority keywords bug_status assigned_to
Message-ID: <bug-106008-4-HQ4myfOJW7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106008-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106008-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106008

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
           Keywords|missed-optimization,        |
                   |needs-reduction             |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot =
gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> # VUSE <.MEM_699>
> _109 =3D MEM[(struct loadcmd *)_106 + -56B].mapend;
>=20
> my only suspicion is that we somehow isolate (and not optimize as
> unreachable)
> the nloadcmds < 1 case in the preceeding case.

Nope the statement we are diagnosing is guarded by nloadcmds > 1.

A reduced testcase looks like the following, needs -Os -fno-ivopts to
reproduce the diagnostics.  It is somewhat of a fundamental limit of
the analysis since when walking the virtual use-def chain we look for
aliases but q[-1] doesn't alias q[0] but when walking the backedge
we simply arrive at the very same stmt again and interpret it as if
it were within the same context.  That might also be a problem for
passes using walk_aliased_vdefs for other purposes than diagnostics.
I think that when walking a backedge walk_aliased_vdefs would need to
be more careful with interpreting the defs it runs into.

int foo (int n)
{
  int *p =3D __builtin_malloc (n);
  int nloadcmds =3D 0;
  int found =3D 0;
  do
    {
      int *q =3D &p[nloadcmds++];
      *q =3D n;
      if (nloadcmds > 1
          && q[-1] !=3D 7)
        found =3D 1;
    }
  while (nloadcmds < n);
  return found;
}=