This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix gnat.dg/lto20.adb XPASS


> 2018-01-30  Jan Hubicka  <hubicka@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.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]