https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841
--- Comment #4 from dbroemmel <dibr-bugzilla at daswigwam dot de> ---
(In reply to janus from comment #2)
> If OpenMP actually allows this, then it is obviously a regression.
I'm not an OpenMP expert (nor am I too familiar with common blocks). The OpenMP
spec., version 4.5, says on p.184 that the THREADPRIVATE directive gets a list
of comma-separated named variables and named common blocks. p.187 further
states:
• The threadprivate directive must appear in the declaration section of a
scoping unit in which the common block or variable is declared. Although
variables in common blocks can be accessed by use association or host
association, common block names cannot. This means that a common block name
specified in a threadprivate directive must be declared to be a common block in
the same scoping unit in which the threadprivate directive appears.
• If a threadprivate directive specifying a common block name appears in one
program unit, then such a directive must also appear in every other program
unit that contains a COMMON statement specifying the same name. It must appear
after the last such COMMON statement in the program unit.
This to me sounds like it should be allowed or is in fact required? I'm not
quite sure my example is fully correct (due to the comments on variables having
to be SAVEd), but I think this is not what upsets the parsing at this point?
--- Comment #5 from dbroemmel <dibr-bugzilla at daswigwam dot de> ---
'make check-gfortran' with the latest git version (only gfortran compiled)
gives:
=== gfortran Summary ===
# of expected passes 45521
# of unexpected failures 1
# of expected failures 92
# of unsupported tests 79
/tmp/patch/objdir/gcc/testsuite/gfortran/../../gfortran version 8.0.0 20170828
(experimental) (GCC)
