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 6CF0D3858421; Wed,  5 Jul 2023 12:36:27 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CF0D3858421
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688560587;
	bh=SIGQfVTIK/phUiV4M1kJSo24yLruvzpsMASVB6je4h8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lS5/Niucf3V5TbtICmYb3yugkoW3U3Jtrh5o3ok9yWfjMhG/UGvrKlYv2ozE+jzIu
	 elVLIKU3bwxJpQeg/hUxe1KcSnyzVqzaBZ1BCpsEtdFooVz/bCtbRno7Bz7GBF3yhD
	 mR7UEqVSJXrt4LLsnd9WAf3eZx3WOfYQWnVY/AC0=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly
 invalid code on -O3
Date: Wed, 05 Jul 2023 12:36:27 +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: 14.0
X-Bugzilla-Keywords: alias, needs-bisection, 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: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110515-4-zrJAVFeiaQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110515-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110515-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=3D110515

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So IMHO it's the fault of invariant motion moving

_145 =3D MEM[(struct LargeRep *)&Visited + 8B].Slots;

and

_34 =3D MEM[(struct LargeRep *)&Visited + 8B].Capacity;

out of loop 10 as these loads are executed conditional.  They are know
to not trap and that's why LIM doesn't require them unconditionally
executed but as we can see here CSE later takes advantage of undefinedness
if there's a load using the wrong TBAA type not matching the dynamic type
of the storage.

For example

char storage[4] __attribute__((aligned(4)));
double foo (int n, int kind)
{
  double res;
  for (int i =3D 0; i < n; ++i)
    if (kind)
      res =3D *(int *)storage;
    else
      res =3D *(float *)storage;
  return res;
}

is transformed to

  <bb 2> [local count: 118111600]:
  if (n_7(D) > 0)
    goto <bb 8>; [89.00%]
  else
    goto <bb 7>; [11.00%]

  <bb 8> [local count: 105119324]:
  _2 =3D MEM[(float *)&storage];
  _1 =3D MEM[(int *)&storage];

  <bb 3> [local count: 955630225]:
  # i_16 =3D PHI <i_13(9), 0(8)>
  if (kind_10(D) !=3D 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 477815112]:
  res_12 =3D (double) _1;
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 477815112]:
  res_11 =3D (double) _2;

  <bb 6> [local count: 955630225]:
  # res_3 =3D PHI <res_12(4), res_11(5)>
  i_13 =3D i_16 + 1;
  if (n_7(D) > i_13)
    goto <bb 9>; [89.00%]
  else
    goto <bb 7>; [11.00%]

  <bb 9> [local count: 850510901]:
  goto <bb 3>; [100.00%]

  <bb 7> [local count: 118111600]:
  # res_15 =3D PHI <res_3(6), res_6(D)(2)>
  return res_15;

and then eventually to the following, unconditionally using float as alias =
set.

  <bb 2> [local count: 118111600]:
  if (n_7(D) > 0)
    goto <bb 3>; [89.00%]
  else
    goto <bb 6>; [11.00%]

  <bb 3> [local count: 105119324]:
  _2 =3D MEM[(float *)&storage];
  if (kind_10(D) !=3D 0)
    goto <bb 4>; [50.00%]
  else
    goto <bb 5>; [50.00%]

  <bb 4> [local count: 52559662]:
  _4 =3D VIEW_CONVERT_EXPR<int>(_2);
  res_12 =3D (double) _4;
  goto <bb 6>; [100.00%]

  <bb 5> [local count: 52559662]:
  res_11 =3D (double) _2;

  <bb 6> [local count: 118111600]:
  # res_15 =3D PHI <res_11(5), res_6(D)(2), res_12(4)>
  return res_15;=