[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #13 from dbroemmel --- Created attachment 42089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42089=edit testcase for the fix (runtime checks) A new testcase that possibly checks runtime behaviour. The snippet is pretty verbose and not too elegant I guess, but it checks what I pieced together how BLOCK DATA and THREADPRIVATE might behave. I've tested it with (older version of) gfortran, xlf, ifort, and pgfortran and none of those abort. A more recent version of gfortran fails to compile. Added as a test for dejagnu (to gfortran.dg/gomp), 7.2.0 fails. A 'fixed' version of 7.2.0 doesn't fail the test.
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #11 from dbroemmel --- Created attachment 42083 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42083=edit testcase for the fix I'm not sure this is the test you had in mind. A fresh gcc-7.2.0 shows an unexpected failure while a 'patched' gcc-7.2.0 doesn't. Still don't know how dejagnu works, but I copied what I found in other blockdata tests.
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #10 from dbroemmel --- (In reply to janus from comment #9) > This seems to be PR 81018 (which translates into "not your fault"). Good :) > I'm happy for now. Backed by your OpenMP quotes, the patch looks pretty > solid to me. Can I add again: I've not checked (and wouldn't quite know how to) if this Fortran/OpenMP syntax would require any GOMP machinery to work that's not there yet. I did write a few simple minded tests for myself if the outcome of a binary is what I would expect and it did seem work. I also assume that as it did work prior to 4.9.x, all the OpenMP parts are there and work as expected and only the syntax check in the parser failed. And I don't take credit for the patch. It's what the OpenMP-forum entry suggested. > Do you feel confident enough to turn your small example into a dejagnu test > case to be committed along with the patch? We'll also need a short ChangeLog > entry for both. I'm afraid not right now. I have no idea how dejagnu works. I can try and devote some more time to it tomorrow, but I can't promise anything.
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #8 from dbroemmel --- (In reply to janus from comment #7) > Sounds unrelated to your patch (supported by the fact that the 6.2 testsuite > runs cleanly), however I haven't seen that failure on trunk recently. That's what I thought as well. > Maybe you can check if it also occurs without the patch on your machine > (i.e. with a clean trunk)? It wasn't a clean trunk but the single line commented and it still shows the same unexpected failure. I can run more tests if you tell me which ones.
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #6 from dbroemmel --- Created attachment 42066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42066=edit summary of make check-gfortran for 8.0.0
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #4 from dbroemmel --- (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 --- 'make check-gfortran' with the latest git version (only gfortran compiled) gives: === gfortran Summary === # of expected passes45521 # of unexpected failures1 # of expected failures 92 # of unsupported tests 79 /tmp/patch/objdir/gcc/testsuite/gfortran/../../gfortran version 8.0.0 20170828 (experimental) (GCC)
[Bug fortran/81841] [5/6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 --- Comment #3 from dbroemmel --- I ran 'make check-gfortran' with version 6.2.0 and the added line in parse.c. Here's the result: === gfortran Summary === # of expected passes42612 # of expected failures 78 # of unsupported tests 71 /tmp/objdir/gcc/testsuite/gfortran/../../gfortran version 6.2.0 (GCC)
[Bug fortran/44350] accepts illegal fortran in BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350 dbroemmel changed: What|Removed |Added CC||dibr-bugzilla at daswigwam dot de --- Comment #9 from dbroemmel --- Please have a look at Bug 81841 which seems to be related to this fix.
