From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 879D239450DC; Fri, 16 Oct 2020 16:55:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 879D239450DC 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 16:55:40 +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 16:55:41 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 --- Comment #20 from rguenther at suse dot de --- On October 16, 2020 5:46:28 PM GMT+02:00, amacleod at redhat dot com wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97360 > >--- Comment #19 from Andrew Macleod --- >(In reply to rguenther@suse.de from comment #18) >> On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com >>=20 >> > >> >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); > ^^^^^^^^^^^^^^ > >This is why types_compatible_p() fails. before checking sign and >precision >matching, it does: > > inner_type =3D TYPE_MAIN_VARIANT (inner_type); > outer_type =3D TYPE_MAIN_VARIANT (outer_type); > > if (inner_type =3D=3D outer_type) > return true; > >/* Changes in machine mode are never useless conversions because the >RTL > middle-end expects explicit conversions between modes. */ > if (TYPE_MODE (inner_type) !=3D TYPE_MODE (outer_type)) > return false; > >and since the modes are now different, it never gets to check the sign >and >precision.... (which do match). > > > >> > layout_type (vector_quad_type_node); >>=20 >> Why not put the fix here instead of in build distinct type copy??=20 >>=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? >>=20 >> Quite sure.=20 > > >I could fix it right there... but it wont prevent something similar >from >happening elsewhere. Anyone changing the mode of the new distinct type >will >continue to allow types_incompatible_p() types for MIN and MAX. > >Maybe its not a big deal, but it just seems like a glaring >inconsistency to me. >If you ask for distinct type, you should get one, complete with >distinct >elements so you don't need to worry about things like this. > >It doesn't seem like powerpc is doing anything wrong, but they are >getting an >inconsistent type back due to the way types_compatible_p checks things. > >Now, looking further into it, this would appear to be the only 2 places >in all >the architectures where build_distinct_type_copy() is called, and then >the mode >is changed. All the other places build a type then set the mode >rather than >getting a copy.=20 > >I'd still prefer to fix it at its source, but given the lack of >prevalence, I >could just set the MIN MAX properly here where these 2 types are having >their >mode changed.=20=20=20 > >Is this your preferred solution? The backen should use more lowlevel functions to build this type rather than copying from a type that isn't appropriate. Off my head it wants fixup_unsigned_type after setting the mode and eventually a different funct= ion to build the original type. See tree.c where we build for example boolean_type_node >diff --git a/gcc/config/rs6000/rs6000-call.c >b/gcc/config/rs6000/rs6000-call.c >index 9fdf97bc803..1fcb438ef95 100644 >--- a/gcc/config/rs6000/rs6000-call.c >+++ b/gcc/config/rs6000/rs6000-call.c >@@ -12917,6 +12917,13 @@ rs6000_init_builtins (void) > tree oi_uns_type =3D make_unsigned_type (256); > vector_pair_type_node =3D build_distinct_type_copy (oi_uns_type); > SET_TYPE_MODE (vector_pair_type_node, POImode); >+ // Changing modes makes the types incompatable. >+ TYPE_MIN_VALUE (vector_pair_type_node) >+ =3D wide_int_to_tree (vector_pair_type_node, >+ wi::to_wide (TYPE_MIN_VALUE >(oi_uns_type))); >+ TYPE_MAX_VALUE (vector_pair_type_node) >+ =3D wide_int_to_tree (vector_pair_type_node, >+ wi::to_wide (TYPE_MAX_VALUE >(oi_uns_type))); > layout_type (vector_pair_type_node); > lang_hooks.types.register_builtin_type (vector_pair_type_node, > "__vector_pair"); >@@ -12924,6 +12931,13 @@ rs6000_init_builtins (void) > 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); >+ // Changing modes makes the types incompatable. >+ TYPE_MIN_VALUE (vector_quad_type_node) >+ =3D wide_int_to_tree (vector_quad_type_node, >+ wi::to_wide (TYPE_MIN_VALUE >(xi_uns_type))); >+ TYPE_MAX_VALUE (vector_quad_type_node) >+ =3D wide_int_to_tree (vector_quad_type_node, >+ wi::to_wide (TYPE_MAX_VALUE >(xi_uns_type))); > layout_type (vector_quad_type_node); > lang_hooks.types.register_builtin_type (vector_quad_type_node, > "__vector_quad"); > >. > > >>=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. >>=20 >> If precision and sign are the same then types_compatible_p will >return true. > >except in cases like this :-P=