Hi Jakub,
this is v4 of the uses_allocators patch.

On 2022/5/31 6:02 PM, Jakub Jelinek wrote:
> 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...

I've adjusted the checking to enforce these rules, and updated the testcases.
Re-tested without regressions.

> 5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just
>     look how it is handled for private too

As discussed in the other mail, private() for FIELD_DECLs on target constructs
seem not working properly, filed PR105861 for this.

Currently uses_allocators (which also uses private) is still sorry() for FIELD_DECLs
in this v4 patch. Will file another issue to track after patch is committed.

(ChangeLog should be the same as before, so omitted here)

Thanks,
Chung-Lin