> > 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

Reply via email to