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
