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); 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? 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.
