https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jürgen Reuter from comment #22) > (In reply to Thomas Koenig from comment #20) > > (In reply to Iain Sandoe from comment #16) > > > (In reply to Thomas Koenig from comment #14) > > > > > There is always the reason of not breaking compatibility, a quick look > > at close_units() shows that it is not meant to be called twice, > > so combining both methods is likely to cause headaches. > > > > So, something for the next incompatible libgfortran update, maybe. > > > > Maybe flushing all units on program termination would be safer, but > > I am not sure we should put in a workaround for what appears to > > be a bug in the underlying system (hopefully soon to be fixed), > > especially since there seems to be a workaround in user code. > > I agree that if this an OS bug, then workarounds in libgfortran that might > jeopardize the integrity are hard to justify. Well, we certainly would not want to do compromise integrity, in any event; that would not be a solution. However, ensuring a single call to the function ought to be feasible. the secondary point I made was that the phasing of DTORs called from cxa_atexit (C++) c.f. directly from a destructor can cause subtle issues in any case. >Do we know that this will be > fixed let's say for macOS 12.0.2 or so, and when will that come? I have filed a bug report, (FB9733712). It is impossible to know what the OS release priorities are (or schedules), but I do know that the Apple OSS folks are very supportive of gfortran, so I expect they will help. > At the > moment these things do break quite a lot of build scripts for software that > rely on redirecting output from test programs. Changing all those test > programs to iso_fortan_env is tedious (but doable).
