public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>
Subject: Re: [Patch] Fortran/OpenMP: Improve associate-name diagnostic [PR103039]
Date: Fri, 18 Mar 2022 17:38:11 +0100	[thread overview]
Message-ID: <YjS1c7XiLf9udyOs@tucnak> (raw)
In-Reply-To: <6e5a585d-9876-cc66-413d-3cad381ddbdf@codesourcery.com>

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


  reply	other threads:[~2022-03-18 16:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-18 16:27 Tobias Burnus
2022-03-18 16:38 ` Jakub Jelinek [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-03-18 13:15 Tobias Burnus
2022-03-18 13:21 ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YjS1c7XiLf9udyOs@tucnak \
    --to=jakub@redhat.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).