This patch assumes that EXEC_OMP_ALLOCATE/EXEC_OMP_ALLOCATORS is/will be later handled as currently
done in OG13, https://github.com/gcc-mirror/gcc/blob/devel/omp/gcc-13/gcc/fortran/trans-openmp.cc

Depending how we want to handle it in mainline, the patch still could make sense
- or parts should be modified, e.g. we might want to handle standard Fortran allocation (malloc)
and OpenMP one (GOMP_alloc) directly in trans-sstmt.cc; if so, we might want to skip adding another
allocate-stmt. - We probably still want to do the 'allocate' and diagnostic hanlding in openmp.cc
in all cases.

In any case, we surely need to handle on mainline:
* the dump-parse-tree.cc patch is surely needed and without removing
the empty entry (n->sym == NULL), it needs an additional fix in order not to crash.
* Rejecting coarrays in the empty-list case, which presumably makes most
   sense inside openmp.cc.

* * *

On mainline, an executable '!$omp allocate' / '!$omp allocators' stops
in trans-openmp.cc with a sorry, not yet implemented.
However, OG13 has some implementation for executable '!$omp allocate';
trying to merge mainline into OG13, I found the following issues:

* -fdump-parse-tree did not dump the clauses (trivial issue)
   (simple oversight)
* The not-specified items should be better handled
   => done now during resolution in openmp.cc.

* * *

While -fdump-tree-original can be used to test it, the "sorry" makes
it hard to write a testsuite test. Some testcases exist like
gfortran.dg/gomp/allocate-5.f90, which contains code similar to the
last example, but it is only a parse + 'sorry'-shows-up testcase.
(Well, the two new 'error:' cases can be tested and are tested but
they are more boring.)

* * *

The spec states:

For
   !$omp allocators allocate(align(4):a,b)
   allocate(a,b,c,d)
only a and b are allocated with an OpenMP allocator (→ omp_get_default_allocator())
and alignment of 4. - 'c' and 'd' are allocated in the normal Fortran way.

The deprecated works as follows:
   !$omp allocate(a,b) align(4)
   !$omp allocate align(16)   ! not: no list argument after 'allocate')
   allocate(a,b,c,d)
where a and b will be allocated with an alignment of 4 and the rest,
here, c and d, with the settings of the directive without argument list,
i.e. c and d are allocated with an alignment of 16.

The question is what is supposed to happen for:
   !$omp allocate(a,b) align(4)
   allocate(a,b,c,d)
Should that use the default allocator for c and d, i.e. the same as
   !$omp allocate(a,b) align(4)
   !$omp allocate
   allocate(a,b,c,d)

Or should it use the normal Fortran allocator, following what 'allocators' does?

The spec does not really tell (and that syntax is deprecated in 5.2, removed in
TR11/OpenMP 6). Thus, GCC now prints an error.  However, it would be trivial to
choose either of the other variants.

* * *

The attached patch now handles the not-specified items:
* It adds them in the last case to the list; namelist->sym == NULL
   is the no-arguments case; this item is also removed, avoiding
   n->sym == NULL special cases later on.
* For the first two cases, a new Fortran ALLOCATE statement is created,
   containing the non-treated items.

Comments, suggestions, remarks?

Tobias
-----------------
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