[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:cdc34b505796327b3eee9e97bc5f27ba71fd9e7a

commit r11-397-gcdc34b505796327b3eee9e97bc5f27ba71fd9e7a
Author: Thomas Koenig 
Date:   Thu May 14 18:30:27 2020 +0200

Add early return for invalid STATUS for close.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* io/close.c (close_status): Add CLOSE_INVALID.
(st_close): Return early on invalid STATUS parameter.

2020-05-14  Thomas Koenig  

PR libfortran/95119
* testsuite/libgomp.fortran/close_errors_1.f90: New test.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Thomas Koenig  ---
This looks simple enough.  Regression-testing as I write this.

@@ -31,7 +31,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If
not, see
 #endif

 typedef enum
-{ CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
+{ CLOSE_INVALID = - 1, CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
 close_status;

 static const st_option status_opt[] = {
@@ -61,6 +61,12 @@ st_close (st_parameter_close *clp)
 find_option (&clp->common, clp->status, clp->status_len,
 status_opt, "Bad STATUS parameter in CLOSE statement");

+  if (status == CLOSE_INVALID)
+{
+  library_end ();
+  return;
+}
+
   u = find_unit (clp->common.unit);

   if (ASYNC_IO && u && u->au)

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

--- Comment #4 from Thomas Koenig  ---
So, in order for this to hang, two close statements
on the same unit are needed, the first one with an
error message.

Seems like the unit is not unlocked on the error return.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

Thomas Koenig  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #3 from Thomas Koenig  ---
I had a hope that

https://gcc.gnu.org/pipermail/fortran/2020-January/053926.html

would already have fixed it, but that doesn't appear to be the
case.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-14
 CC||tkoenig at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Koenig  ---
Confirmed with current trunk.

[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119

--- Comment #1 from Bill Long  ---
Appears to be a regression. 

The original submitter thinks it is hanging in  __lll_lock_wait inside CLOSE. 

Th same hang can be observed if the references to omp_get_num_threads are
removed, but you still compile with -fopenmp (even though there is no openmp in
the code).  Appears to be related to linking with -lpthreads.