On Mon, Apr 15, 2024 at 09:38:29AM +0200, Jakub Jelinek wrote:
> I had this spot instrumented to log the different cases (before adding the
> code to fix up also pointer types in c_update_type_canonical) and the only
> thing
> that triggered was that the 2 TYPE_CANONICALs weren't equal if
> TYPE_STRUCTURAL_EQUALITY_P (TREE_TYPE (t)), the other was just in case.
> gcc.c-torture/compile/20021205-1.c
> gcc.c-torture/compile/20040214-2.c
> gcc.c-torture/compile/20060109-1.c
> gcc.c-torture/compile/pr113623.c
> gcc.c-torture/compile/pr46866.c
> gcc.c-torture/compile/pta-1.c
> gcc.c-torture/execute/pr33870-1.c
> gcc.c-torture/execute/pr33870.c
> gcc.dg/torture/pr57478.c
> tests were affected in make check-gcc.
> I thought it would be a clear consequence of the choice we've discussed on
> IRC, that build_pointer_type_for_mode and other tree.cc functions which
> lookup/create derived types don't try to fill in TYPE_CANONICAL for
> types derived from something which initially had TYPE_STRUCTURAL_EQUALITY_P
> but later changed to non-TYPE_STRUCTURAL_EQUALITY_P. The patch updates
> it solely for qualified types/related pointer types, but doesn't do that
> for array types, pointer to array types, function types, ...
> So, I think the assertion could still trigger if we have something like
> -O2 -flto -std=c23
> struct S;
> typedef struct S *T;
> typedef T U[10];
> typedef U *V;
> V foo (int x) { return 0; }
> struct S { int s; };
> (but doesn't, dunno what I'm missing; though here certainly V and U have
> TYPE_STRUCTURAL_EQUALITY_P, even T has because it is a typedef, not
> something actually normally returned by build_pointer_type).
Though, haven't managed to reproduce it with -O2 -flto -std=c23
struct S;
typedef struct S **V[10];
V **foo (int x) { return 0; }
struct S { int s; };
either.
So, maybe let's drop the ipa-free-lang-data.cc part?
Seems fld_incomplete_type_of uses fld_type_variant which should
copy over TYPE_CANONICAL.
Jakub
