On Wed, Jan 31, 2018 at 12:02 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> 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.
Ah, right. The patch oversimplifies this. We need to do sth like
TREE_CODE (t1) == ARRAY_TYPE && ! TYPE_NONALIASED_COMPONENT (t1) && ...
right?
Richard.
> --
> Eric Botcazou
