From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A37F73943408; Tue, 20 Oct 2020 06:23:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A37F73943408 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit Date: Tue, 20 Oct 2020 06:23:27 +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: rguenth 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: 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: Tue, 20 Oct 2020 06:23:27 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 --- Comment #31 from Richard Biener --- (In reply to Andrew Macleod from comment #30) > 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? Yes. > > Don't we want a distinct type compared to the > > unsigned type returned from make_unsigned_type()? But make_unsigned_type already returns a distinct type. It's a low-level worker unless for example make_nonstandard_integer_type which caches types. > 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? >=20 > tree > make_unsigned_type (int precision) > { > =C2=A0 tree type =3D make_node (INTEGER_TYPE); >=20 > =C2=A0 TYPE_PRECISION (type) =3D precision; >=20 > =C2=A0 fixup_unsigned_type (type); > =C2=A0 return type; > } >=20 >=20 > 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. >=20 > it sure *seems* like that is a resonable fix.=C2=A0 Its not like that fir= st=20 > node is creating a system wide node? >=20 > our type system is a bit, umm, flakey,=C2=A0 but it seems reasonable to m= e.=C2=A0=C2=A0=20 > :-)=C2=A0 And its in the spirit of what his patch was doing... >=20 > What could possibly go wrong? :-) :-) Nothing. > Andrew=