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 090983858C33; Thu,  8 Feb 2024 01:18:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 090983858C33
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707355087;
	bh=2GLiDJRXs9dKu0X7pgewDQqKz2BEPoAeA2Iok5q4umk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=qwmkVf8fBLp5Z516j5vDIAF0ldt5D3SyEcn+mJYSWzdYgNLycHbFVZvxZ8Hea4zIJ
	 XwGVL+RO9ALMXOUffhYY8RQPWVPV1IFddKt1FLpcN1M/OJzbw7UdOOeRDhBULy+/1p
	 wAy6Y+ct53Gb8xaE2zCW4S/GvHLIee1e6vMJJPbA=
From: "liuhongt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs 
 r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
Date: Thu, 08 Feb 2024 01:18:04 +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: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: liuhongt at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113576-4-spIljH1MB7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113576-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113576-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=3D113576

--- Comment #37 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #36)
> For example with AVX512VL and the following, using -O -fgimple -mavx512vl
> we get simply
>=20
>         notl    %esi
>         orl     %esi, %edi
>         cmpb    $15, %dil
>         je      .L6
>=20
> typedef long v4si __attribute__((vector_size(4*sizeof(long))));
> typedef v4si v4sib __attribute__((vector_mask));
> typedef _Bool sbool1 __attribute__((signed_bool_precision(1)));
>=20
> void __GIMPLE (ssa) foo (v4sib v1, v4sib v2)
> {
>   v4sib tem;
>=20
> __BB(2):
>   tem_5 =3D ~v2_2(D);
>   tem_3 =3D v1_1(D) | tem_5;
>   tem_4 =3D _Literal (v4sib) { _Literal (sbool1) -1, _Literal (sbool1) -1,
> _Literal (sbool1) -1, _Literal (sbool1) -1 };
>   if (tem_3 =3D=3D tem_4)
>     goto __BB3;
>   else
>     goto __BB4;
>=20
> __BB(3):
>   __builtin_abort ();
>=20
> __BB(4):
>   return;
> }
>=20
>=20
> the question is whether that matches the semantics of GIMPLE (the padding
> is inverted, too), whether it invokes undefined behavior (don't do it - it
> seems for people using intrinsics that's what it is?) or whether we
> should avoid affecting padding.
>=20
> Note after the patch I proposed on the mailing list the constant mask is
> now expanded with zero padding.

I think we should also mask off the upper bits of variable mask?

        notl    %esi
        orl     %esi, %edi
        notl    %edi
        andl    $15, %edi
        je      .L3=