From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id C87B2385840D for ; Tue, 19 Dec 2023 21:35:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C87B2385840D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C87B2385840D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703021729; cv=none; b=QvNNDSumtn43HE0K77ahOTBWy0+ijHMQ3Fzy21XPMJ/3PG+iryBdMgEXhw8cNDd5fy7ITcJs9LeqgrFxP0LSsZkKbIm68EAxSeTSwQxA1rTu60kHuAX4dVWnQ7V730p+e66cco6EkabGOFAl4Xcgp31hR6gMeuYzE790NTzeK7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703021729; c=relaxed/simple; bh=V8mL9tk1uygnk20Ir8XoSlf9BbcwPPrHOu65LGhCqX0=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=g+1xM3EKxbuCefS2+zqyhJyFWlZzth8f/SPH2X/0e6GdU5SrafkoBjdokPAzNh5/V5YBxdFE7Nr1wi7yAHqCn4psk0qTEXnBjf0ZEDzwcT+nAodmOv5mEKHBNnyw/kFixs/05iWkCKqcv0mTyFMCGHjI+kRRQAkFwSY+4zU8AV0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 3BJLZQCK090863; Tue, 19 Dec 2023 13:35:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 3BJLZPj6090862; Tue, 19 Dec 2023 13:35:25 -0800 (PST) (envelope-from sgk) Date: Tue, 19 Dec 2023 13:35:25 -0800 From: Steve Kargl To: Harald Anlauf Cc: fortran Subject: Re: libgfortran, ABI, and F2018 enhancements to intrinsics? Opinions wanted Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Dec 19, 2023 at 09:07:08PM +0100, Harald Anlauf wrote: > Dear all, > > in Fortran 2018 a few intrinsics were extended and now support > additional optional arguments. See PR 85836 for the meta-bug, > and in particular: > > 96583 - get_environment_variable > 96584 - get_command > 96585 - get_command_argument > > with an optional ERRMSG. > > How are we going to deal with this? At one time, we kept track of things that would break libgfortran's ABI on the wiki. You can find the list at https://gcc.gnu.org/wiki/LibgfortranAbiCleanup. This could be old and moldy as I haven't checked in on ABI changes in a long time. > If we do not want to break the existing ABI, so that we can > link gfortran-13 and gfortran-14+(?) compiled code, we need > to keep _gfortran_get_command_i4 & friends, and introduce > new library functions that are able to handle the new > requirements. > > Do we have recommendations for a naming scheme? > Like _gfortran_F2018_get_command_i4 > or _gfortran_get_command_F2018_i4, or better? The only convention that I can recall is the _gfortran_ prefix and the kind type suffix _i4. > Would it be sufficient to update gfortran.map suitably? If you add a new symbol, then yes, gfortran.map would need to be updated to contain it. > Or do we need to bump something else? If you change the ABI of, say, get_command() you would need to bump the major version number for libgfortran. > And would that be fine, given that 14-development is in stage-3? > Or rather wait for the next stage-1? In the past gfortran developers have had some leeway in making this type of change in stage-3, because the change would only affect gfortran (unless you somehow manage to break bootstrap). For these changes, I think we need create new symbols. I'm not a fan of encoding F2018 into the name as the 'new' optional arguments are present in F2023. Perhaps, a simple version number _gfortran_get_command_v1_i4. -- Steve