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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Thomas Koen
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.
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 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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 compi
