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 2B77A3870865; Mon, 27 Apr 2020 09:35:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2B77A3870865
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1587980148;
 bh=JDmqImRq0I+faEyocuCcldi7YVoeqjxyz1+N9Ci5trk=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=AKEkKtkbPyGt0q9NYAFGoqenjWGqx4l6pKzAg93WNOL+jbzpy6xewhy9lymKDDrnh
 ZiqsEisf0RurmIb1oK4c6bK9RiF/fsjwut2aNoOZcnRrJYeJ2ziVtEJnnyPZ+fw+sT
 HrBfVpSgocnos2An6C8YhR5kulOEXS3A8bFnHuPI=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57359] store motion causes wrong code for
 union access at -O3
Date: Mon, 27 Apr 2020 09:35:48 +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: 4.9.0
X-Bugzilla-Keywords: alias, 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-57359-4-8mvUaEfxpI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57359-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57359-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 09:35:48 -0000

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

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
And another testcase showing that with a conditional invariant store we may
_never_ apply store-motion since conditional means we do not know the
original order of stores in the loop.  *sigh*

typedef int A;
typedef float B;

float x[256];

void __attribute__((noinline,noclone))
foo(long unk, long ack)
{
  B *q =3D x;
  for (long i =3D 0; i < unk; ++i)
    {
      q[i] =3D 42;
      if (ack & i)
        *((A*)q + 4) =3D 1;
    }
}

int main(void)
{
  foo(5, 3);
  if (x[4] !=3D 42) __builtin_abort();
  return 0;
}


implementation-wise it should still work, in hoist_memory_references, when
we computed the whole set of refs to apply store-motion to in a loop,
track the sequencing of stores from entry to the latch edge and at
merge points reject (parts of?) the sequence when there are mismatches
in ordering.  For the above there'd be { q[i], *((A*)q + 4) } and { q[i] }
and thus a mismatch.  If we reject only parts of the sequence those
parts would need to be disambiguated against the previous stores in the
sequence w/o TBAA.

Trying to code that up now.=