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