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 DC0C63857402; Fri,  9 Sep 2022 09:31:11 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC0C63857402
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1662715871;
	bh=rASnxADxRfe4Mj53zzg4wLv6BvG/4m+oVNYXLujIfRI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=ufpUgHlYgZfLGuLdrRed6GT+LQ0YP+O5lZHEt9ialW6OsovAuh7QP1dmDj/fGw1Pg
	 wWxt9Bet5FmaBOBNicL/I0eBsgG3i5ooYY6ga9WWeWLHOdo60bwrFBmV4Nal66ZE/u
	 tBpGEv+/TGU5Kmup0PvcKpfk43AE6jUYsd9tRlMw=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on
 x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
Date: Fri, 09 Sep 2022 09:31:11 +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: 13.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106892-4-PyVBwEOpsR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106892-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106892-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=3D106892

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the reason is that we have

  # RANGE [-2147483643, 2]
  _137 =3D 4 - prephitmp_80;
 f[_137] =3D _139;

which makes us conclude the f[_137] access is constrained to f[0..2].  When
we see

  _75 =3D MEM[(int *)_20 + 16B];

we then disambiguate because iff _20 points into 'f' then with offset 16
it's beyond that constrained access.  _But_!

  # RANGE [18446744065119617028, 18446744073709551608]
  _5 =3D _39 * -4U;
  # PT =3D anything
  _20 =3D &f + _5;

_20 is actually _before_ 'f' which we consider invalid.

Now here's what the frontend presents us with:

      f[4 - d] =3D f[4 - d] ^ 3;

which we eventually gimplify to

  _5 =3D 4 - d.1_4;
  _6 =3D f[_5];

but then predictive commoning comes along:

Load motion chain 0x43bb3d0
  inits MEM[(int *)_20 + 16B]
  references:
    f[_2] (id 0)
      offset 0
      distance 0
    f[_2] (id 1, write)
      offset 0
      distance 0

Executing predictive commoning without unrolling

   <bb 36> [local count: 35740571]:
+  _39 =3D (sizetype) prephitmp_80;
+  _5 =3D _39 * 18446744073709551612;
+  _20 =3D &f + _5;
+  _75 =3D MEM[(int *)_20 + 16B];

   <bb 11> [local count: 289173710]:
   # ivtmp_48 =3D PHI <ivtmp_68(22), 7(36)>
+  # f_I_lsm0.27_12 =3D PHI <f_I_lsm0.27_1(22), _75(36)>
   _2 =3D 4 - prephitmp_80;
-  _3 =3D f[_2];
+  _3 =3D f_I_lsm0.27_12;

introducing this kind of problem.  We have a "opt-out" with using
TARGET_MEM_REF which is exempt from this rule because IVOPTs also likes to
break it.=