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.
