------- Comment #17 from jakub at gcc dot gnu dot org 2007-02-08 09:36 ------- When writing the unit locking code, I relied on Fortran95 requiring that the same unit isn't used recursively, you can use different units, but not the same. gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with -fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase is IMHO not valid Fortran95 source.
Now, if Fortran2003 allows some recursive access to the same unit (under which conditions?), then the gfc_unit's lock could very well be changed into __gthread_recursive_mutex_t as well as the initializer, perhaps together with adding a recursion count (as the recursion count in __gthread_recursive_mutex_t isn't portably accessible) to gfc_unit as well. The question is how much is libgfortran prepared for changes happening to gfc_unit happening between say st_write and st_write_done calls (st_write normally calls get_unit and thus acquires gfc_unit's lock, which is held until st_write_done calls unlock_unit). For Fortran95, if a hang is in your opinion not a good implementation of undefined behavior when running a buggy program, if recursive mutex is used for gfc_unit's lock and a recursion counter is present, then anyone calling gfc_unit could then check the recursion count and if it is bigger than 1, unlock_unit it again and report an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617