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 6282F3858C5E; Tue, 31 Oct 2023 06:40:31 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6282F3858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1698734431;
	bh=uoSH+Q/ChLQsBbQp2ckLmbu0s8wFBmXdgGY39B0G/7E=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=gUcBsrGV1LmPuYkqUlmXYDoU7ck4LXSyAP1hokapowtr/6oU/hbSfXSSDgaP6kD0T
	 jAo/FY9mc3dkJ2aT5+I/Rskdu49Q8B4we5hAXzPZZ7290ssbPCI7mgpzPvpPvdSX9o
	 WSYdoMcToDdsvVnHWW0kYYu6yEvC7UBpIdVaDAK0=
From: "linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111591] ppc64be: miscompilation with -mstrict-align /
 -O3
Date: Tue, 31 Oct 2023 06:40:29 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: needs-bisection
X-Bugzilla-Severity: normal
X-Bugzilla-Who: linkw 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-111591-4-W8jsuyZBGT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111591-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111591-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=3D111591

--- Comment #32 from Kewen Lin <linkw at gcc dot gnu.org> ---
> case pass, but the original test case (#c1) can't pass with this, it can't
> pass with -fstack-reuse=3Dnone + -fno-strict-aliasing + -O2 either, I thi=
nk
> the original case still suffers another latent bug.

Well, I spent some time to narrow down the remaining issue on #c1 and found=
 the
test case reduction generated unexpected test source (uninitialized array w=
hich
is used for assert comparison), it locates at below lines 438 to line 439:

   428  struct TestSatWidenMulPairwiseAdd {
   429    template <typename TN, class DN> void operator()(TN, DN dn) {
   430      using TN_U =3D MakeUnsigned<TN>;
   431      using TW =3D MakeWide<TN>;
   432      RepartitionToWide<DN> dw;
   433      using VW =3D Vec<decltype(dw)>;
   434      using VN =3D Vec<decltype(dn)>;
   435      size_t NN =3D Lanes(dn), NW =3D Lanes(dw), kMaxLanesPerNBlock =
=3D
sizeof(TN),
   436             kMaxLanesPerWBlock =3D sizeof(TW);
   437      RebindToUnsigned<decltype(dn)> dn_u;
   438      VW f0;
   439      VN nf0, nf1 =3D Set(dn, TN{});
   440      AssertVecEqual(dw, f0, SatWidenMulPairwiseAdd(dw, BitCast(dn_u,
nf0), nf0),
   441                     "", 0);


The expected result is f0 while the one used for the following
SatWidenMulPairwiseAdd computation is nf0, both are not initialized.
I'd expect they are initialized, like:

  VW f0 =3D Set(dw, TW{});
  VN nf0 =3D Set(dn, TN{});

So IMHO #c1 test case is problematic, hi @Mathieu, could you have a double
check?=