https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On October 16, 2020 4:17:43 PM GMT+02:00, amacleod at redhat dot com <gcc-bugzi...@gcc.gnu.org> wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 > >--- Comment #17 from Andrew Macleod <amacleod at redhat dot com> --- >(In reply to rguent...@suse.de from comment #16) >> On Fri, 16 Oct 2020, amacleod at redhat dot com wrote: >> >> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 >> > >> > --- Comment #15 from Andrew Macleod <amacleod at redhat dot com> >--- >> > Well it seems far more incorrect that types_compatible_p () is >FALSE for a type >> > and its MIN/MAX value? >> >> 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. > >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. > > >> >> 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 = make_unsigned_type (512); > vector_quad_type_node = 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?? 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... >Perhaps the type should be created some other way rather than >distinct_type? Quite sure. > >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. > >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.
