On Wed, Mar 09, 2022 at 07:04:24PM +0800, Chung-Lin Tang wrote:
> Now in OpenMP 5.x, static members are supposed to be not a barrier for a class
> to be target-mapped.
>
> There is the related issue of actually providing access to static
> const/constexpr
> members on the GPU (probably a case of
> https://github.com/OpenMP/spec/issues/2158)
> but that is for later.
>
> This patch basically just removes the check for static members inside
> cp_omp_mappable_type_1, and adjusts a testcase. Not sure if more tests are
> needed.
> Tested on trunk without regressions, okay when stage1 reopens?
>
> Thanks,
> Chung-Lin
>
> 2022-03-09 Chung-Lin Tang <clt...@codesourcery.com>
>
> gcc/cp/ChangeLog:
>
> * decl2.cc (cp_omp_mappable_type_1): Remove requirement that all
> members must be non-static; remove check for static fields.
I don't see anything useful left in cp_omp_mappable_type{,_1}.
In particular, starting with OpenMP 5.0, for both C and C++ we just say
that a mappable type is a complete type. True, for C++ there is also the
"All member functions accessed in any target region must appear in a
declare target directive."
and similarly for Fortran, but that isn't something we really can check when
we ask whether something is a mappable type, that isn't a property of a
type, but a property of the target region.
In OpenMP 4.5 the special C++ mappable_type langhooks was useful, both for
the non-static data members and for virtual methods.
So, I think instead of your patch, we should just throw away
cp_omp_mappable_type{,_1}, and as C++ was the only one that had a special
langhook, I think we should kill the langhook altogether too, move
lhd_omp_mappable_type from langhooks.cc to omp-general.cc or so
as omp_mappable_type and use that instead of the langhooks or
cp_omp_mappable_type.
Now, the C++ FE has also cp_omp_emit_unmappable_type_notes while other FEs
don't, either we can just say that type doesn't have mappable type
like the C FE does, or perhaps just can emit a note that it isn't a mappable
type because it is incomplete (but then it would be nice to do the same
thing in the C FE too).
Jakub
