On Fri, Mar 18, 2022 at 05:27:02PM +0100, Tobias Burnus wrote:
> SELECT TYPE, SELECT RANK and ASSOCIATE have
> associate-name => selector
> and create a pointer to the selector.
>
> GCC was fixed to handle CLASS properly in
> class(t) :: var
> !$omp ... firstprivate(var)
> As a side effect, firstprivate(assoc_name) now also gets
> handled that way, effectively trying to firstprivate(selector)
> which should be shared...
>
> While firstprivate(var) does not appear explicitly, it gets
> added via gfc_omp_predetermined_sharing.
>
> I went for the simple solution and handle it only
> in gfortran's ctor/dtor.
>
> An alternative would be to set OMP_CLAUSE_FIRSTPRIVATE_NO_REFERENCE,
> which is currently only set for C++'s __for_end / __for_range
> and then later process it in ctor/dtor. I am not sure whether that's
> really best and what's the best way to propagate it. One way would
> be to create and use OMP_CLAUSE_DEFAULT_FIRSTPRIVATE_NO_REFERENCE.
>
> OK as is (simple version) – or is a fuller version better. If so,
> suggestion how to do this best?
LGTM.
> Fortran/OpenMP: Fix privatization of associated names
>
> gfc_omp_predetermined_sharing cases the associate-name pointer variable
> to be OMP_CLAUSE_DEFAULT_FIRSTPRIVATE, which is fine. However, the associated
> selector is shared. Thus, the target of associate-name pointer should not get
> copied. (It was before but because of gfc_omp_privatize_by_reference returning
> false, the selector was not only wrongly copied but this was also not done
> properly.)
>
> gcc/fortran/ChangeLog:
>
> PR fortran/103039
> * trans-openmp.cc (gfc_omp_clause_copy_ctor, gfc_omp_clause_dtor):
> Only privatize pointer for associate names.
>
> libgomp/ChangeLog:
>
> PR fortran/103039
> * testsuite/libgomp.fortran/associate4.f90: New test.
>
> gcc/fortran/trans-openmp.cc | 10 +++
> libgomp/testsuite/libgomp.fortran/associate4.f90 | 92
> ++++++++++++++++++++++++
> 2 files changed, 102 insertions(+)
>
Jakub
