From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B879C3858C62; Thu, 22 Feb 2024 07:47:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B879C3858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1708588044; bh=KUA7RnHYlzoDEcfHQvocEySbrrwahjT3s+QVAiBcO9I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bFQpZPoUk52pE2DMNp9HwVCm3wo5DiUSlqXMu0P0cGnPlkZN6T1U/DNaEbnnQYHXj 4FSzlIfXMmGWE7rmo+L4yOb1S2scjco7CqBWRv3ZM3IjObZ3kiNR0CjW+yQBeZ64el bFu3lkYmStrCAR664ddKcEFyz4Pfvj/tLsLPMEhA= From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470 Date: Thu, 22 Feb 2024 07:47:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de 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: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113988 --- Comment #19 from rguenther at suse dot de --- On Wed, 21 Feb 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113988 >=20 > --- Comment #17 from Jakub Jelinek --- > So, either we could somehow handle that case during expansion (treat it > basically as VCE), or tweak the > /* For integral conversions with the same precision or pointer > conversions use a NOP_EXPR instead. */ > (simplify > (view_convert @0) > (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) > && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE = (@0))) > && TYPE_PRECISION (type) =3D=3D TYPE_PRECISION (TREE_TYPE (@0))) > (convert @0))) > match.pd rule not to do that for INTEGER_TYPEs with PRECISION > > MAX_FIXED_TYPE_PRECISION (then we don't need the gimple-lower-bitint.cc c= hanges > either). > --- gcc/match.pd.jj 2024-02-19 09:42:16.583617451 +0100 > +++ gcc/match.pd 2024-02-21 13:32:06.567816298 +0100 > @@ -4679,7 +4679,13 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > (view_convert @0) > (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) > && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE > (@0))) > - && TYPE_PRECISION (type) =3D=3D TYPE_PRECISION (TREE_TYPE (@0))) > + && TYPE_PRECISION (type) =3D=3D TYPE_PRECISION (TREE_TYPE (@0)) > + /* Punt for conversions from or to barely supported huge > + INTEGER_TYPEs. Those can handle just loads/stores/moves but > + nothing else. */ > + && (TYPE_PRECISION (type) <=3D MAX_FIXED_MODE_SIZE > + || (TREE_CODE (type) !=3D INTEGER_TYPE > + && TREE_CODE (TREE_TYPE (@0)) !=3D INTEGER_TYPE))) > (convert @0))) >=20 > /* Strip inner integral conversions that do not change precision or size= , or I think the usual BLKmode check would be better here? Apart from that this looks correct, we shouldn't use a regular convert on a non-register type. In fact, it looks like all bitint types are register types because we want SSA names for them. A bit of a "bad" design ... We've used BLKmode checks elsewhere so I think it would be appropriate here, too.=