> > 2018-01-30 Jan Hubicka <hubi...@ucw.cz> > > > > gcc: > > PR lto/83954 > > * lto-symtab.c (warn_type_compatibility_p): Silence false positive > > for type match warning on arrays of pointers. > > > > gcc/testsuite: > > PR lto/83954 > > * gcc.dg/lto/pr83954.h: New testcase. > > * gcc.dg/lto/pr83954_0.c: New testcase. > > * gcc.dg/lto/pr83954_1.c: New testcase. > > That being said, I'm not convinced that the patch is correct: > > + /* Alias sets of arrays are the same as alias sets of the inner > + types. */ > + while (TREE_CODE (t1) == ARRAY_TYPE && TREE_CODE (t2) == ARRAY_TYPE) > + { > + t1 = TREE_TYPE (t1); > + t2 = TREE_TYPE (t2); > + } > > That's not always true, see get_alias_set: > > /* Unless the language specifies otherwise, treat array types the > same as their components. This avoids the asymmetry we get > through recording the components. Consider accessing a > character(kind=1) through a reference to a character(kind=1)[1:1]. > Or consider if we want to assign integer(kind=4)[0:D.1387] and > integer(kind=4)[4] the same alias set or not. > Just be pragmatic here and make sure the array and its element > type get the same alias set assigned. */ > else if (TREE_CODE (t) == ARRAY_TYPE > && (!TYPE_NONALIASED_COMPONENT (t) > || TYPE_STRUCTURAL_EQUALITY_P (t))) > set = get_alias_set (TREE_TYPE (t)); > > and gnat.dg/lto20.adb is very likely in the TYPE_NONALIASED_COMPONENT case.
OK, so you think the test above should check && (!TYPE_NONALIASED_COMPONENT (t1) || TYPE_STRUCTURAL_EQUALITY_P (t1)) && (!TYPE_NONALIASED_COMPONENT (t2) || TYPE_STRUCTURAL_EQUALITY_P (t2)) Do we have wrong code issue with lto20.adb? Honza > > -- > Eric Botcazou