[Bug libfortran/30617] recursive I/O hangs under OSX

jakub at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Thu Feb 8 09:36:00 GMT 2007



------- 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



More information about the Gcc-bugs mailing list