[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL
TYPE_CANONICAL is just an optimization to speed up type comparisons (but it
seems c-typeck.cc doesn't actually use that, so it is mainly middle-end then).
See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at least
one TYPE_CANONICAL is NULL (aka TYPE_STRUCTURAL_EQUALITY_P), and otherwise at
least without checking will rely on TYPE_CANONICAL comparison and that is it.
So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as long as
comptypes etc. works correctly).  Having TYPE_CANONICAL non-NULL and not
actually matching could cause type comparisons to think types are the same when
they aren't or vice versa.

Now, when you set TYPE_CANONICAL on completion of the flag_isoc23 aggregates,
you could surely also update TYPE_CANONICAL of the variant types using
build_qualified_type and perhaps pointers too, just to handle the common case. 
But unlike the case where the TYPE_CANONICAL of the aggregate TYPE_MAIN_VARIANT
would be initially different, you wouldn't need to chase down everything,
including TYPE_CANONICAL on FUNCTION_TYPE which have pointers to array type of
array type of pointer of pointer of qualified pointer to the aggregate etc.,
just the common things.
And setting TYPE_CANONICAL just based on the tag would be also wrong, if one
can define struct S { int s; }; in one scope and struct S { int a, b; }; in
another scope and those types are supposed to be different.