https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, build_qualified_type sets TYPE_CANONICAL of qualified types to either the
returned type or build_qualified_type of the TYPE_CANONICAL of the base type.
So, updating TYPE_CANONICAL of the variants to TYPE_CANONICAL of the base type
looks always wrong, it would need to recompute the TYPE_CANONICAL using
build_qualified_type instead. But, similarly to build_qualified_type,
build_pointer_type, build_array_type etc. also similarly set TYPE_CANONICAL to
something based on the TYPE_CANONICAL.
So, if you really need to update TYPE_CANONICAL after type is completed, I'd at
least do it only if the new TYPE_CANONICAL is actually different from the base
type, otherwise don't update anything, and if you do update, one needs to also
recompute TYPE_CANONICAL on all the pointer types (those can be found through
for (t = TYPE_POINTER_TO (to_type); t; t = TYPE_NEXT_PTR_TO (t))),
but one would need to do that recursively to also update the **, ***, **** etc.
pointers), but also all created ARRAY_TYPEs (the shared ones can be found in
type_hash_table but non-shared can't), FUNCTION_TYPEs etc.
Which makes me wonder if for flag_isoc23 it wouldn't be better to
SET_TYPE_STRUCTURAL_EQUALITY on incomplete structure/union types and therefore
also on any POINTER_TYPE, ARRAY_TYPE, FUNCTION_TYPE, ... derived from that, and
only set
TYPE_CANONICAL when the aggregate is completed. Yes, it will be slower to
compare
some of the types because one won't be able to use TYPE_CANONICAL, but given
the above it seems really hard to recompute TYPE_CANONICAL on everything that
could have been derived from TYPE_CANONICAL (type) = type of the incomplete
type when it will be later changed.
