https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83295
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- This testcase is invalid in OpenMP 4.0 and 4.5, it will be valid only in the upcoming OpenMP 5.0 which isn't supported yet. The bug is that because there is no explicit mapping or data sharing clause on the #pragma omp target construct and c is used in the region, it implies map(to:c) and so asks mapping 1024*sizeof (int) bytes when the previous target enter data directive only mapped 768*sizeof (int) bytes from that array. The fix is easy, just add map(to:c[0:size]) (or map(alloc:c[0:size]) or whatever, if not using always the mapping kind is irrelevant when it is already mapped) to the #pragma omp target construct. OpenMP 5.0 will make this valid by saying in 2.20.6.1 map Clause section of http://www.openmp.org/wp-content/uploads/openmp-TR6.pdf : "If a single contiguous part of the original storage of a list item with an implicit data-mapping attribute has corresponding storage in the device data environment prior to a task encountering the construct associated with the map clause, only that part of the original storage will have corresponding storage in the device data environment as a result of the map clause." Without this paragraph, implicit map clause is treated the same as explicit one and there is the requirement that if it is asking for the whole array storage and only a portion of it is mapped, then it is unspecified behavior, in gcc runtime error.