From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1F80B3858432; Mon, 1 Nov 2021 17:41:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1F80B3858432 From: "tkoenig at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0 Date: Mon, 01 Nov 2021 17:41:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tkoenig at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2021 17:41:59 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102992 --- Comment #20 from Thomas Koenig --- (In reply to Iain Sandoe from comment #16) > (In reply to Thomas Koenig from comment #14) > NOTE: I have been discussing the non-running of mod_term_funcs with my > "downstream" and Apple folks. The consensus is that this is 99.99% likely > an unintentional bug that just happens not to show with clang-based > toolchains because they queue DTORs on atexit (as does GCC for C++). >=20 > > I guess that could be put into main, after the call to __MAIN, instead. >=20 > Well, unless there's a good reason to have it in a DTOR, it makes for a m= ore > robust solution to call it directly (there are various other differences > that could occur in mixed code bases esp. c++ + fortran even without the > Darwin21.1 bug). 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.=