public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Andrew Stubbs <ams@codesourcery.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Fortran List <fortran@gcc.gnu.org>
Subject: Re: [PATCH] OpenMP front-end: allow requires dynamic_allocators
Date: Sat, 15 Jan 2022 13:43:54 +0100	[thread overview]
Message-ID: <20220115124354.GW2646553@tucnak> (raw)
In-Reply-To: <39b6e9f5-aa51-c78d-dd51-cb6a6b91e5f9@codesourcery.com>

On Mon, Dec 20, 2021 at 03:16:23PM +0000, Andrew Stubbs wrote:
> This patch removes the "sorry" message for the OpenMP "requires
> dynamic_allocators" feature in C, C++ and Fortran.
> 
> The clause is supposed to state that the user code will not work without the
> omp_alloc/omp_free and omp_init_allocator/omp_destroy_allocator and these
> things *are* present, so there should be no problem allowing it.
> 
> I can't see any reason for our implementation to *do* anything with this
> statement -- it's fine for the allocators to work the same with or without
> it.

Well, we should do a lot with it, but that can wait for later.
In particular, if OMP_REQUIRES_DYNAMIC_ALLOCATORS is not present,
we should be rejecting omp_init_allocator and omp_destroy_allocator
in target regions (maybe just a warning though), and for allocate clauses,
directives, and the omp_alloc etc. APIs we should in the target region
enforce they don't use omp_null_allocator and the allocators they use
is mentioned in uses_allocators (and implement uses_allocators).
But, right now it is unclear to me how exactly is that supposed to work
with declare target to routines, those aren't nested inside of the target
and so can't know what uses_allocator is used, so they can't make any
allocations?  Or is it just that we can't diagnose this in such routines
and only can diagnose omp_null_allocator isn't used...
> 
> I think this patch ought to be fine for GCC 12, but if not it can wait until
> stage 1 opens. I shall backport this to OG11 shortly.

Anyway, your patch is a step forward, as we don't support uses_allocators,
the non-requires dynamic_allocators way is unusable for any target region
allocations due to that and so requires dynamic_allocators is the only thing
we actually support, but we were rejecting that directive...

Ok and sorry for the delay.

> gcc/c/ChangeLog:
> 
> 	* c-parser.c (c_parser_omp_requires): Don't "sorry" dynamic_allocators.
> 
> gcc/cp/ChangeLog:
> 
> 	* parser.c (cp_parser_omp_requires): Don't "sorry" dynamic_allocators.
> 
> gcc/fortran/ChangeLog:
> 
> 	* openmp.c (gfc_match_omp_requires): Don't "sorry" dynamic_allocators.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gfortran.dg/gomp/requires-8.f90: Reinstate dynamic allocators
> 	requirement.

	Jakub


      reply	other threads:[~2022-01-15 12:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 15:16 Andrew Stubbs
2022-01-15 12:43 ` Jakub Jelinek [this message]

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=20220115124354.GW2646553@tucnak \
    --to=jakub@redhat.com \
    --cc=ams@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /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).