From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9AD683894C31; Mon, 19 Oct 2020 23:28:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9AD683894C31 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit Date: Mon, 19 Oct 2020 23:28:19 +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: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com 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: 11.0 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 23:28:19 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 --- Comment #30 from Andrew Macleod --- On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 > > --- Comment #28 from Peter Bergner --- > (In reply to Andrew Macleod from comment #25) >> Wonder if it was suppose to be something like: >> >> >> /* Vector pair and vector quad support. */ >> if (TARGET_EXTRA_BUILTINS) >> { >> - tree oi_uns_type =3D make_unsigned_type (256); >> - vector_pair_type_node =3D build_distinct_type_copy (oi_uns_type); >> + vector_pair_type_node =3D make_unsigned_type (256); >> SET_TYPE_MODE (vector_pair_type_node, POImode); >> layout_type (vector_pair_type_node); >> lang_hooks.types.register_builtin_type (vector_pair_type_node, >> "__vector_pair"); >>=20=20=20 >> - tree xi_uns_type =3D make_unsigned_type (512); >> - vector_quad_type_node =3D build_distinct_type_copy (xi_uns_type); >> + vector_quad_type_node =3D make_unsigned_type (512); >> SET_TYPE_MODE (vector_quad_type_node, PXImode); >> layout_type (vector_quad_type_node); >> lang_hooks.types.register_builtin_type (vector_quad_type_node, > So this passed bootstrap and regtesting with no regressions. > > Is this really the correct fix? Don't we want a distinct type compared t= o the > unsigned type returned from make_unsigned_type()? > I actually dont know, Richi might have to comment on that.. Nothing was=20 referring to the original unsigned_type that was created?=C2=A0 Its just=20 orphaned? tree make_unsigned_type (int precision) { =C2=A0 tree type =3D make_node (INTEGER_TYPE); =C2=A0 TYPE_PRECISION (type) =3D precision; =C2=A0 fixup_unsigned_type (type); =C2=A0 return type; } All it does is create a new node, then fixup goes and creates the MIN=20 and MAX fields and sets a few other little things.=C2=A0=C2=A0=C2=A0=C2=A0 = The only reason=20 we saw the old unsigned type is we were picking it up from the MAX and=20 MIN fields,... which=C2=A0 were set to the original type. it sure *seems* like that is a resonable fix.=C2=A0 Its not like that first= =20 node is creating a system wide node? our type system is a bit, umm, flakey,=C2=A0 but it seems reasonable to me.= =C2=A0=C2=A0=20 :-)=C2=A0 And its in the spirit of what his patch was doing... What could possibly go wrong? :-) :-) Andrew=