public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Andrew Stubbs <ams@codesourcery.com>
Cc: Chung-Lin Tang <cltang@codesourcery.com>,
	Tobias Burnus <tobias@codesourcery.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	Catherine Moore <clm@codesourcery.com>,
	Hafiz Abid Qadeer <abid_qadeer@mentor.com>
Subject: Re: [PATCH, OpenMP, v2] Implement uses_allocators clause for target regions
Date: Thu, 19 May 2022 19:55:12 +0200	[thread overview]
Message-ID: <YoaEgJDipuPOILOD@tucnak> (raw)
In-Reply-To: <8334c3f4-32ef-c840-6b32-ec33e4db1654@codesourcery.com>

On Thu, May 19, 2022 at 06:02:43PM +0100, Andrew Stubbs wrote:
> On 19/05/2022 17:00, Jakub Jelinek wrote:
> > Without requires dynamic_allocators, there are various extra restrictions
> > imposed:
> > 1) omp_init_allocator/omp_destroy_allocator may not be called (except for
> >     implicit calls to it from uses_allocators) in a target region
> 
> I interpreted that more like "omp_init_allocator/... is not required to
> work", as in the set-up steps provided by dynamic_allocators/uses_allocators
> won't be available. Since we don't have any such on/off mode I don't believe
> we need to worry about this (and adding extra logic for this is make-work
> which will not improve the user-experience).

Unfortunately OpenMP as the standard doesn't bother too much with
distinctions that e.g. the C/C++ standards make, whether something makes the
TU invalid or whether something is only invalid at runtime when reaching it.
In any case, I think it would be nice if we diagnosed such uses, doesn't
need to be an error, warning would be fine, but help users write portable
code, either that they requires dynamic_allocators, or don't and limit
themselves to what the standard says should be used in that case.
I guess a warning might be better, because we really don't know if it will
be actually called at runtime or not from the target region.

> > 2) omp_alloc etc. can't be called with omp_null_allocator and the argument
> >     has to be a constant expression for a predefined memory allocator
> >     (that is also mentioned on uses_allocators, though that doesn't have to
> >     be visible in the source because it could be lexically included in
> >     a target construct's body)
> 
> Again, does a conforming implementation reject this, or is it merely not
> required to accept it?

I think it is another fuzzy area, but again it would be nice to at least
get warnings.

	Jakub


  reply	other threads:[~2022-05-19 17:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 13:20 [PATCH, OpenMP] " Chung-Lin Tang
2022-05-06 16:40 ` Tobias Burnus
2022-05-10 11:29   ` [PATCH, OpenMP, v2] " Chung-Lin Tang
2022-05-19 16:00     ` Jakub Jelinek
2022-05-19 17:02       ` Andrew Stubbs
2022-05-19 17:55         ` Jakub Jelinek [this message]
2022-05-20  6:59       ` Tobias Burnus
2022-05-19 17:46     ` Jakub Jelinek
2022-05-30 14:43       ` Chung-Lin Tang
2022-05-30 17:23         ` Jakub Jelinek
2022-05-31 10:02           ` Jakub Jelinek
2022-06-06 13:19             ` Chung-Lin Tang
2022-06-06 13:22               ` Jakub Jelinek
2022-06-06 13:38                 ` Chung-Lin Tang
2022-06-06 13:42                   ` Jakub Jelinek
2022-06-09  6:21             ` [PATCH, OpenMP, v4] " Chung-Lin Tang
2022-06-09 12:22               ` Jakub Jelinek
2022-06-13 13:29                 ` Chung-Lin Tang
2022-06-13 14:04                   ` Jakub Jelinek
2023-02-09 11:26 ` [og12] '{c-c++-common,gfortran.dg}/gomp/uses_allocators-*' -> 'libgomp.{c-c++-common,fortran}/uses_allocators-*' (was: [PATCH, OpenMP] Implement uses_allocators clause for target regions) Thomas Schwinge

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=YoaEgJDipuPOILOD@tucnak \
    --to=jakub@redhat.com \
    --cc=abid_qadeer@mentor.com \
    --cc=ams@codesourcery.com \
    --cc=clm@codesourcery.com \
    --cc=cltang@codesourcery.com \
    --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).