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 EA2593858D3C; Thu, 29 Jun 2023 07:13:32 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EA2593858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688022812;
	bh=Upt7ePUEsQR89jBHe5MRcCCziWpX9X2H+uJBPptJUIk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=R4m1Mb+VccNXnFhoW8PmPF9+Ww5ZnzE/eIQkdkzABthki3bTtC0Wd3iygVTGoTeSA
	 1SbfC3aQhffEx+12/gyFWGLXJFDl2uRnyDzEkvaXi8SIq2TlqgDbPgkzfngEFE0myD
	 Vc2diq8nwkYAi5G9/3G+wuodhp1GJc8Nb+5ohEt0=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/110461] [14 regression] ICE when building
 openh264 with new vector_type checking
Date: Thu, 29 Jun 2023 07:13:32 +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: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110461-4-RG1CJk1u0m@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110461-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110461-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=3D110461

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> Yes it is that pattern, specifically :
> /* Try to fold (type) X op CST -> (type) (X op ((type-x) CST))
>    when profitable.
>    For bitwise binary operations apply operand conversions to the
>    binary operation result instead of to the operands.  This allows
>    to combine successive conversions and bitwise binary operations.
>    We combine the above two cases by using a conditional convert.  */
> (for bitop (bit_and bit_ior bit_xor)
>  (simplify
>   (bitop (convert@2 @0) (convert?@3 @1))
>   (if (((TREE_CODE (@1) =3D=3D INTEGER_CST
>          && INTEGRAL_TYPE_P (TREE_TYPE (@0))
>          && (int_fits_type_p (@1, TREE_TYPE (@0))
>              || tree_nop_conversion_p (TREE_TYPE (@0), type)))
>         || types_match (@0, @1))
>        && !POINTER_TYPE_P (TREE_TYPE (@0))
>        && TREE_CODE (TREE_TYPE (@0)) !=3D OFFSET_TYPE
>        /* ???  This transform conflicts with fold-const.cc doing
>           Convert (T)(x & c) into (T)x & (T)c, if c is an integer
>           constants (if x has signed type, the sign bit cannot be set
>           in c).  This folds extension into the BIT_AND_EXPR.
>           Restrict it to GIMPLE to avoid endless recursions.  */
>        && (bitop !=3D BIT_AND_EXPR || GIMPLE)
>        && (/* That's a good idea if the conversion widens the operand, th=
us
>               after hoisting the conversion the operation will be narrowe=
r.
>               It is also a good if the conversion is a nop as moves the
>               conversion to one side; allowing for combining of the
> conversions.  */
>            TYPE_PRECISION (TREE_TYPE (@0)) < TYPE_PRECISION (type)
>            /* The conversion check for being a nop can only be done at the
> gimple
>               level as fold_binary has some re-association code which can
> conflict
>               with this if there is a "constant" which is not a full
> INTEGER_CST.  */
>            || (GIMPLE && TYPE_PRECISION (TREE_TYPE (@0)) =3D=3D TYPE_PREC=
ISION
> (type))
>=20
> Those 2 above TYPE_PRECISION .

For vectors this also lacks a check the resulting bit operation is supporte=
d.
I'm testing a patch.=