------- Comment #27 from dominiq at lps dot ens dot fr 2007-04-24 13:03 ------- > Please define "fixed".
For me "fixed"=="no hanging" period. > You run an invalid program, Yes, I know, repeating that won't help! > all you need is change your expectations what will happen. Bugzilla has plenty of entries "ICE on invalid", I am just asking that "hanging on invalid" is not brushed aside just because it does happen on a platform some people don't like. > It is the same as if you write > pthread_mutex_t m; > pthread_mutex_init (&m, NULL); > pthread_mutex_lock (&m); > pthread_mutex_lock (&m); > The deadlock might be detected or might not, at which point it would hang. As far as I can tell, without knowledge of the 'pthread_mutex' mechanism, the problem does not occur at this level, but at the level of: pthread_mutex_unlock (&m) pthread_mutex_unlock (&m) where the first 'unlock' releases all the previous locks dealing with the same unit number, leaving the second 'unlock' "waiting for something that is not coming". Something like: pthread_mutex_init (&m, NULL); pthread_mutex_lock (&m); pthread_mutex_init (&m1, NULL); pthread_mutex_lock (&m1); ... pthread_mutex_unlock (&m1) pthread_mutex_unlock (&m) is working (see comment #19), so probably if &m refers to some "event" and not to some "unit number" (not being ashamed to show my ignorance) the problem would disappear. I think the following answer from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d3caadeb9083808e/78c9e65c8b4f930e?lnk=gst&q=recursive&rnum=11#78c9e65c8b4f930e summarize the discussion Even if this restriction on recursive input/output is unnecessary or undesireable, it is, nonetheless, a part of the Fortran 2003 standard. Note the "unnecessary or undesireable", leading me to the following comments: (1) the use of recursive I/O can be detected at run time: xlf does it; I guess that a second locking of '&m' would not be too difficult to detect and I don't buy the efficiency argument at this level (gfortran did not strike me as being any faster than xlf on I/O operations); (2) the behavior, however "processor" (fortran meaning) dependent it is, should be platform independent: just imagine the port to OSX of a 100kloc code where one such recusive I/O used for debuging on Linux (it works) has been left; (3) I repeat that I am not asking for an immediate fix, only that the problem is not forgotten due to the 'invalid' label. Anyway, thanks for the answer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617