https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114959
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Martin Uecker from comment #2) > The GCC FE has all the necessary logic to compute type compatibility and > this could easily be adapted to compute equivalence classes and then set a > TYPE_CANONICAL. All function types in the same class would get the same > TYPE_CANONICAL even if a little bit different, i.e. return pointers to > compatible but slightly different array types. I think function arguments > we need to ignore completely, because > > T (*f)(); > > is compatible with all pointers to functions with the same return type. > (this is gone in C23 though) Or we special case such functions. > > What is unclear to me whether function types are the only remaining issue or > whether this should then be done for all types (pointers, arrays, etc)? I think function types are somewhat special in that they do not denote objects in the classical sense. They are also most complex and probably target-dependent to handle. Note there's LTO where we glob all pointers to a single equivalence class because of Fortran where C_PTR inter-operates with all pointer types. But LTO would compute FUNCTION_TYPE TYPE_CANONICAL in a less conservative way than required for the above rule for C. That said, we do not stream TYPE_CANONICAL into the LTO IL but instead attempt to recompute it (for the sole purpose of TBAA) in a way compatible with all language frontends (without considering possible knowledge of frontends involved in the link).
