From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:3]) by sourceware.org (Postfix) with ESMTPS id 4032C3858C2C; Sat, 30 Oct 2021 10:31:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4032C3858C2C Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 8157611F88; Sat, 30 Oct 2021 12:31:13 +0200 (CEST) Received: from [IPv6:2001:4dd7:5748:0:7285:c2ff:fe6c:992d] (2001-4dd7-5748-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:5748:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin1.netcologne.de (Postfix) with ESMTPSA id E8B3811DF0; Sat, 30 Oct 2021 12:31:00 +0200 (CEST) From: Thomas Koenig Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch) To: Jakub Jelinek Cc: Michael Meissner , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , David Edelsohn , Peter Bergner , Bill Schmidt References: <20211004100754.GL304296@tucnak> <00657799-e00e-dcf7-acd1-f07da196e767@netcologne.de> <20211030100326.GK304296@tucnak> Message-ID: <78b71846-512d-19cf-c444-aa6eb758f58c@netcologne.de> Date: Sat, 30 Oct 2021 12:31:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211030100326.GK304296@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: E8B3811DF0 X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 10:31:17 -0000 Hi Jakub, > On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote: >> - Have a compiler switch which selects between IEEE_QP and IBM_QP. >> This was a suggestion by Steve Lionel formerly of DEC and Intel, >> and they did that when they had a few floating point formats on >> the Alpha to choose from. We would then have to specially annotate >> the KIND=16 library routines, and also maybe indicate the different >> argument types in module files. Anything else would be user error. >> They also had the CONVERT options to go with it. >> >> Question: Which option would we want to pursue? I actually think the >> fourth one (the suggestion by Steve Lionel) is the best one. > > That was the last option I was mentioning in the initial mail > https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html > > Copying it here: > > Or the last option would be to try to make libgfortran.so.5 ABI compatible > with both choices on powerpc64le-linux. From quick skimming of libgfortran, > we have lots of generated functions, which use HAVE_GFC_REAL_16 and > GFC_REAL_16 etc. macros. So, we could perhaps arrange for the compiler > to use r16i or r17 instead of r16 in the names when real(kind=16) is the > IEEE quad on powerpc64le and keep using r16 for the IBM double double. That is quite doable. > For the *.F90 generated files, one could achieve it by making sure > the *r16* files are compiled with -mabi=ibmlongdouble, for > *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in > those, for *.c generated files the *GFC_* macros could just ensure that > it doesn't use long double but __ibm128 or __float128 depending on which one > is needed. Yep. > But then I see e.g. the io routines to just pass in kind and so > switch (kind) // or len > { > case ...: > *(GFC_REAL_*) = ...; > } > etc. Could we just pretend in the compiler to libgfortran ABI that > powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything > would actually think it is 17 bytes it uses 16 instead (though, kind=10 > on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?). That is not something I would like to have, for purposes of cleanness. We can always switch at run-time to a different function. This branch should be rather well-predicted, and additional execution will be insignificant compared to the rest of the I/O. > > That solution would most closely match what we do e.g. for C/C++, especially > libstdc++ or glibc, we already have an option to select that - > -mabi=ibmlongdouble vs. -mabi=ieeelongdouble and default selected during > configure. libgfortran would be ABI compatible with both ABIs, but user > binaries or libraries wouldn't be. Similarly to C, there is no different > mangling of user symbols. Hm, there's a difference. I meant that we can select this at compile time for the user, and we should at least consider adding a flag to the module files if the routine has been compiled for IBM_QP or IEEE_QP. We should not change the mangling of the routine names themselves, I agree. Best regards Thomas