[Patch] Fortran/OpenMP: Add omp loop [PR99928]

Tobias Burnus tobias@codesourcery.com
Wed Jun 2 22:30:50 GMT 2021

This patch adds support for 'omp loop' to gfortran including the combined
constructs. It also fixes some splitting issues with clauses in
combined constructs.

It does not attempt to clean up all remaining Fortran issues with
clauses in combined constructs (cf. below + PR).

  * * *

Since 'parallel loop' is now supported, using
  !$omp parallel &
  !$acc& loop
no longer gave an error. (Same result before: '!$acc& do'.)

With the current unpatched parser, there is either everything
successfully parsed – and and processed – or it fails with
MATCH_NO and gfortran tries it again with another different
match attempt. The error is cached and only shown, when
still pending and nothing else worked.
Using gfc_error_now prevents the delayed/conditional output
but as several matching attempts are done, the error is show
half a dozen times.

I played around, but I then determined that it
is the simplest to abort with a fatal error in this case.
Hence, I split the testcase into three – and placed it into the
goacc-gomp directory (where it belongs to but which did not
exist for quite some time).
(The early parse errors + the first fatal error can be in one
file, the next fatal error needs an extra file and
resolution-time errors must be yet in another file.)
As the name 'omp*.f*' did not fit any more, I renamed it.

   !$omp foo
   !$acc bar
is not a continuation line – which was mishandled in
fixed-form Fortran (cf. mixed-omp-3.f + scanner.c)
- causing a bogus error as no continuation line was involved.

Not in this testcase, but if the first statement is either
an '!$xxx end ...' or a single-statement where nothing
follows, this could prevent valid fixed-form code from
running ...

  * * *

This patch includes all Fortranized pr99928-3.c testcases, except for
pr99928-9.c and pr99928-10.c, which use array sections in 'reduction'.
Additionally, 'defaultmap(none)' is currently commented as it is not yet

Regarding the xfails: There are some shared() ones and the target map(tofrom),
which I did not attempt to fix in this patch. And I observe the following
fails in pr99928-7.f90:

The check does (for Fortran – and alike for C):
   ! { dg-final { scan-tree-dump-not "omp distribute\[^\n\r]*lastprivate\\(j00\\)" "gimple" } }
   ! { dg-final { scan-tree-dump-not "omp parallel\[^\n\r]*lastprivate\\(j00\\)" "gimple" } }
   ! { dg-final { scan-tree-dump-not "omp for\[^\n\r]*lastprivate\\(j00\\)" "gimple" } }
   ! { dg-final { scan-tree-dump "omp simd\[^\n\r]*linear\\(j00:1\\)" "gimple" } }
   !$omp distribute parallel do simd default(none)
   do j00 = 1, 64
   end do

While C generates (original dump)

   #pragma omp distribute
       #pragma omp parallel default(none)
             #pragma omp for nowait
                 #pragma omp simd

Fortran generates the same except for:
                     #pragma omp simd linear(j00:1)

The latter leads to a different result for the gimple dump. Fortran has:
   #pragma omp distribute private(j00.1)
         #pragma omp parallel default(none) lastprivate(j00)
             #pragma omp for nowait private(j00.0)
                   #pragma omp simd linear(j00:1)
while C has the same without 'lastprivate(j00)'.

And the dump checks that 'lastprivate(j00)' does not appear ...

  * * *

OK? – Comments, remarks?


Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omp-loop.diff
Type: text/x-patch
Size: 142149 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210603/4600d631/attachment-0001.bin>

More information about the Gcc-patches mailing list