Re: [PATCH, OpenMP, v2] Implement uses_allocators clause for target regions

[Jakub Jelinek <jakub@redhat.com>]

On Mon, May 30, 2022 at 07:23:55PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, May 30, 2022 at 10:43:30PM +0800, Chung-Lin Tang wrote:
> > > This feels like you only accept a single allocator in the new syntax,
> > > but that isn't my reading of the spec, I'd understand it as:
> > > uses_allocators (memspace(omp_high_bw_mem_space), traits(foo_traits) : bar, baz, qux)
> > > being valid too.
> > 
> > This patch now allows multiple allocators to be specified in new syntax, although I have
> > to note that the 5.2 specification of uses_allocators (page 181) specifically says
> > "allocator: expression of allocator_handle_type" for the "Arguments" description,
> > not a "list" like the allocate clause.
> 
> I guess this should be raised on omp-lang then what we really want.
> Because the 5.1 syntax definitely allowed multiple allocators.

The response I got on omp-lang is that it is intentional that in the new
syntax only a single allocator is allowed.
So I'd suggest to implement:
1) if has_modifiers (i.e. certainly new syntax), only allow a single
   enumerator / identifier for a variable and no ()s after it
2) if !has_modifiers and there is exactly one allocator without ()s,
   treat it like new syntax
3) otherwise, it is the old (5.1) syntax, which allows a list and that
   list can contain ()s for traits, but in the light of the 5.2 wording,
   I'd even for that case avoid diagnosing missing traits for non-predefined
   allocators
4) omp_null_allocator should be diagnosed as invalid,
   private (omp_null_allocator) is rejected...
5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just
   look how it is handled for private too

	Jakub