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

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

[longb at cray dot com]

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

            Bug ID: 95119
           Summary: CLOSE hangs when -fopenmp is specified in compilation
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: longb at cray dot com
  Target Milestone: ---

> cat test3.f90
program test
  integer,external :: omp_get_num_threads
              character(len=16) my_status
              open (unit=10, file='test.dat')
              print *, omp_get_num_threads()
              write (10, *) 'weird'
              rewind (10)
              read (10, *) my_status
              close (10)
              open (unit=10, file='test.dat')
              close (unit=10, status=my_status, iostat=ios)
              print *, ios
              close (10, status='delete')
      end program test

Works fine with gfortran 8.3.0:

> gfortran -fopenmp test3.f90
> ./a.out
           1
        5002
>


Hangs with gfortran 9.3.0:

> gfortran -fopenmp test3.f90
> ./a.out
           1
        5002
^C
> module avail gcc

[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 <longb at cray dot com> ---
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.

[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 <tkoenig at gcc dot gnu.org> 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 <tkoenig at gcc dot gnu.org> ---
Confirmed with current trunk.

[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 <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu.org

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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 <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Kथà¤nig <tkoenig@gcc.gnu.org>:

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

commit r11-397-gcdc34b505796327b3eee9e97bc5f27ba71fd9e7a
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Thu May 14 18:30:27 2020 +0200

    Add early return for invalid STATUS for close.

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

[Bug fortran/95119] [9/10 Regression] 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 <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |9.4
            Summary|CLOSE hangs when -fopenmp   |[9/10 Regression] CLOSE
                   |is specified in compilation |hangs when -fopenmp is
                   |                            |specified in compilation

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Still two revisions to fix.

[Bug fortran/95119] [9/10 Regression] 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 #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
<tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:8275e0a6686b465d4d1717784e3e864305d37d02

commit r10-8170-g8275e0a6686b465d4d1717784e3e864305d37d02
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Thu May 14 18:30:27 2020 +0200

    Add early return for invalid STATUS for close.

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

    (cherry picked from commit cdc34b505796327b3eee9e97bc5f27ba71fd9e7a)
    (cherry picked from commit d975519ad1066ed0397714c91aafadadb52a63dd)

[Bug fortran/95119] [9/10 Regression] 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 #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
<tkoenig@gcc.gnu.org>:

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

commit r9-8615-gf1d34396c264ae15ba7492bd2b800c5764d92134
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Thu May 14 18:30:27 2020 +0200

    Add early return for invalid STATUS for close.

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

    2020-05-14  Thomas Koenig  <tkoenig@gcc.gnu.org>

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

    (cherry picked from commit cdc34b505796327b3eee9e97bc5f27ba71fd9e7a)
    (cherry picked from commit d975519ad1066ed0397714c91aafadadb52a63dd)
    (cherry picked from commit 8275e0a6686b465d4d1717784e3e864305d37d02)

[Bug fortran/95119] [9/10 Regression] 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 #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Closed on all affected branches, after the now-customary battles with git.

[Bug fortran/95119] [9/10 Regression] 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 <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
And now really closing, and thanks for the bug report.

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

[longb at cray dot com]

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

--- Comment #12 from Bill Long <longb at cray dot com> ---
Original submitter asking which GCC version(s) have / will have the fix.

[Bug fortran/95119] [9/10 Regression] 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 #13 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Bill Long from comment #12)
> Original submitter asking which GCC version(s) have / will have the fix.

10.2 already has been released with the fix. 9.4 and 11.1 will have it in when
they are released.