https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79649

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 21 Feb 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79649
> 
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I have:
> 
> --- gcc/tree-loop-distribution.c.jj     2017-01-30 09:31:47.000000000 +0100
> +++ gcc/tree-loop-distribution.c        2017-02-21 09:31:52.484838050 +0100
> @@ -1072,6 +1072,13 @@ classify_partition (loop_p loop, struct
>        /* But exactly one store and/or load.  */
>        for (j = 0; RDG_DATAREFS (rdg, i).iterate (j, &dr); ++j)
>         {
> +         tree type = TREE_TYPE (DR_REF (dr));
> +
> +         /* The memset, memcpy and memmove library calls are only
> +            able to deal with generic address space.  */
> +         if (!ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE (type)))
> +           return;
> +
>           if (DR_IS_READ (dr))
>             {
>               if (single_load != NULL)

I have

Index: gcc/tree-loop-distribution.c
===================================================================
--- gcc/tree-loop-distribution.c        (revision 245601)
+++ gcc/tree-loop-distribution.c        (working copy)
@@ -1072,6 +1072,11 @@ classify_partition (loop_p loop, struct
       /* But exactly one store and/or load.  */
       for (j = 0; RDG_DATAREFS (rdg, i).iterate (j, &dr); ++j)
        {
+         /* Do not generate library calls for accesses involving 
non-generic
+            address-spaces.  */
+         if (! ADDR_SPACE_GENERIC_P (TYPE_ADDR_SPACE
+                       (TREE_TYPE (TREE_TYPE (DR_BASE_ADDRESS (dr))))))
+           return;

are you sure TYPE_ADDR_SPACE is properly on all handled components?
I doubt that we're copying TYPE_FIELDS in the following (you could check 
in the following).  So better look at the base address.

struct A { int a; };

struct A __seg_gs x;
struct A y;

void foo ()
{
  x.a = y.a;
}

Reply via email to