From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E6892385E83A; Fri, 16 Oct 2020 15:02:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E6892385E83A From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit Date: Fri, 16 Oct 2020 15:02:50 +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: rguenther at suse dot de 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: Fri, 16 Oct 2020 15:02:51 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 --- Comment #18 from rguenther at suse dot de --- On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 > >--- Comment #17 from Andrew Macleod --- >(In reply to rguenther@suse.de from comment #16) >> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote: >>=20 >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 >> >=20 >> > --- Comment #15 from Andrew Macleod >--- >> > Well it seems far more incorrect that types_compatible_p () is >FALSE for a type >> > and its MIN/MAX value? >>=20 >> But then this (types_compatible_p () is FALSE) is not going to be >fixed >> by the patch - or at least the type that was copied retains the >issue. >> So it's certainly the wrong place to fix. > >Why doesn't it? it creates new min and maxs based from the old >wide_ints, only >with the new type. So it'll be the correct mina dn max, with the corect >type >set? It now passes the types_compatible_p() test in the testcase.. >because >they are the same type instead of the old type.=20=20 > >Its not an interaction between the old type and the new that is at >issue, its >interaction between the new type and its MIN/MAX values when we are >type >checking something created from the MIN/MAX. > > >>=20 >> Note that for integer subtypes generated by Ada the min/max values >> are in the "parent" type. Usually the types are compatible though >> (same precision and signedness). > >Yeah, I haven't tripped over it in ADA. This was a 512 byte quad on the >powerpc >target.. so far the only place I have seen this issue. > > tree xi_uns_type =3D make_unsigned_type (512); > vector_quad_type_node =3D build_distinct_type_copy (xi_uns_type); > SET_TYPE_MODE (vector_quad_type_node, PXImode); > layout_type (vector_quad_type_node); Why not put the fix here instead of in build distinct type copy??=20 lang_hooks.types.register_builtin_type (vector_quad_type_node, > "__vector_quad") > >The vector_quad ends up with MAX and MIN set to the uint512_t type, >which is >not types_compatible_p...=20=20 >Perhaps the type should be created some other way rather than >distinct_type? Quite sure.=20 > >Im starting to wonder if I should stop trying to assert type >correctness when >processing ranges since our type "system" has too many tweaky >inconsistencies >that we continue to trip over.=20=20 > >Instead, just make sure precision and sign are the same and "trust" >gimple to >be right otherwise. If precision and sign are the same then types_compatible_p will return true= .=