I have now re-diffed the patch and cleaned up some comments, and spend
some time proof reading it myself. And have now committed it as
r14-1301-gd64e8e1224708e7f5b87c531aeb26f1ed07f91ff

As the subject line states, it adds parsing support for "!$omp allocate"
as declarative directive and (if preceded by an executable
statement/directive) as deprecated alias for '!$omp allocators', which
is also supported. — After successful checking, it fails with the usual
"sorry, not yet implemented".

Like always, comments and suggestions are welcome.

Tobias

PS: The real challenge will be to get 'allocators' working as gfortran
currently calls malloc/free/realloc directly and this will not work well
if memory is allocated differently, e.g., by omp_alloc and friends. But
that's a separate issue, unrelated this parsing + error-diagnostic patch.

Probably simpler, especially for stack variables, would be the support
for the declarative 'allocate' directive (in C/C++/Fortran. Except for
some C++ template-handling polishing, the parsing support is there, but
middle-end wiring is still required.)

PPS: I filed a PR regarding the handling of 'structure elements' with
allocators, https://gcc.gnu.org/PR109998

PPPS: I remarked before:

On 21.12.22 16:51, Tobias Burnus wrote:
> On 14.12.22 11:47, Tobias Burnus wrote:
>
>> This patch adds parsing/argument-checking support for
>>   '!$omp allocators allocate([align(int),allocator(a) :] list)'
>
> This follow-up patch additionally adds parsing support for both
> declarative and allocate-stmt-associated '!$omp allocate' directives –
> and replaces my previous patch.
>
> OK for mainline?
>
>  * * *
>
> The code requires in line with OpenMP 5.1 that an executable statement
> comes before an '!$omp allocate' that is associated with a Fortran
> ALLOCATE stmt, which is diagnosed.
>
> Note: There is a spec change/regression related to permitting structure
> elements; while OpenMP 5.0/5.1 did permit them in the
> allocate-stmt-associated "!$omp allocate", OpenMP 5.2 stopped doing –
> and '!$omp allocators' never permitted it. — For allocate that's seems
> to be the accidental result from "permitted unless stated otherwise" to
> "rejected unless stated otherwise". For 'allocators', it is the result
> of the original 'allocate' clause which should have been extended for
> 'allocators' - or should not.
>
> In any case, that's tracked now in OpenMP's spec issue #3437.
>
> Thoughts? – The code rejects var%comp and var(1)%comp etc. for now –
> besides the unclear spec status, I admittedly did this also to make
> checking easier (like for duplicated entries, entry same as in ALLOCATE
> except for tailing array spec etc.).
>
>  * * *
>
> This patch replaced both my previous patch in this thread and also
> Abid's patch
>
>> "[PATCH 1/5] [gfortran] Add parsing support for allocate directive
>> (OpenMP 5.0)."
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603258.html
>
> In his patch set, later patches actually add allocater support for
> allocatables/pointers, only – but there issues with regards to the used
> allocator (see patches + patch review).
>
> As my attached patch raises a sorry, it neither addresses that issue nor
> is it affected by that issue.
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955