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 12F023842AC0; Mon, 20 Feb 2023 14:27:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 12F023842AC0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1676903229;
	bh=FIlTvoTdjpqUdnDf0lUOjnebtMWSs2QwoFexgcve+bA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=aKVhlYRmfgQW1wUHFlQ5c/aRXFobG+ruq+HcJho0bq4c2K/vDRmeqzZt1nnTl7mu8
	 cVMKjotePZZClRu5GGOcxCnnpFisi772PyYsYDl4hlG6HgtlxRA+g9emfmTtUb2B5U
	 FHIKolz9KChWpo+tLQmadwEDg3+UJpxWhnhMwNzw=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108862] [13 Regression] CryptX miscompilation on power9
 since r13-2107
Date: Mon, 20 Feb 2023 14:27:08 +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.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-108862-4-ECSKoWV8Wu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108862-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108862-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=3D108862

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, -O2 -mcpu=3Dpower9:
__attribute__((noipa)) unsigned __int128
foo (unsigned __int128 x, unsigned long long y, unsigned long long z)
{
  return x + (unsigned __int128) y * z;
}

int
main ()
{
  unsigned __int128 x =3D foo (0, 0x04a13945d898c296ULL, 0x0000100000000fff=
ULL);
  if ((unsigned long long) (x >> 64) !=3D 0x0000004a13945dd3ULL
      || (unsigned long long) x !=3D 0x9b1c8443b3909d6aULL)
    __builtin_abort ();
  return 0;
}
works correctly, in that case we get:
        maddhdu 10,5,6,3
        maddld 3,5,6,3
        add 4,10,4
which is correct.  But for the #c0 testcase above, e.g. with -O2
-fno-unroll-loops -mcpu=3Dpower9 we get
.L3:
        ldu 9,8(8)
        ldu 10,-8(5)
        maddld 3,9,10,3
        maddhdu 9,9,10,3
        add 4,9,4
        bdnz .L3
in the inner loop, which looks wrong because maddhdu in that case uses resu=
lt
of maddld as last operand rather than the low part of the 128-bit counter (=
w).=