[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

["muecker at gwdg dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #14 from Martin Uecker <muecker at gwdg dot de> ---
(In reply to Jakub Jelinek from comment #12)
> 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.


According to my understanding, setting based on tag would form larger
equivalence classes, so should give correct code but suboptimal aliasing
analysis.

There are two general issues I see here.

1.) The middle end idea of type compatibility is not necessarily the same as
the language semantics. In particular type compatibility in C is not based on
mutual equivalence, so any mechanism based on forming equivalence classes using
TYPE_CANONICAL can only be an approximation (which to be correct, must be less
precise than the language semantics). 

2.) If compatibility relationship changes for types (as it the case when
completing types, then we either have to use an equivalence class that does not
need to change (e.g. based on tags) or only use structural equivalency, or
upgrade structural equivalency to the  equivalency class for the completed type
if this is allowed.