From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout2.netcologne.de (cc-smtpout2.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:2]) by sourceware.org (Postfix) with ESMTPS id 9D97B385840E; Sat, 30 Oct 2021 09:30:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D97B385840E Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id A4FA0126DD; Sat, 30 Oct 2021 11:30:39 +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-smtpin3.netcologne.de (Postfix) with ESMTPSA id A811511D7A; Sat, 30 Oct 2021 11:30:29 +0200 (CEST) Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch) To: Michael Meissner , Jakub Jelinek , fortran@gcc.gnu.org, gcc@gcc.gnu.org, Tobias Burnus , Segher Boessenkool , David Edelsohn , Peter Bergner , Bill Schmidt References: <20211004100754.GL304296@tucnak> From: Thomas Koenig Message-ID: <00657799-e00e-dcf7-acd1-f07da196e767@netcologne.de> Date: Sat, 30 Oct 2021 11:30:29 +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: 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: A811511D7A X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_MANYTO, 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 09:30:44 -0000 Hi Michael, > It adds target hooks so the back end can overwrite the kind number for types. > I made the IBM long double type use KIND=15 instead of KIND=16, and Float128 > uses KIND=16 as we've discussed. The tests for long double are still > failing, so I suspect we will need some way of signalling about the long double > which uses a funky kind (king=15). There is still no conclusion how to deal with the two 16-bit types. I have also asked on the J3 mailing list, and received a few different opinions and options as well. We can: - Support KIND=16 == IEEE_QP only in the compiler, and supply a CONVERT option from IBM_QP to IEEE_QP only. People who would need the old format (why anybody would do that, I have no idea, but some may) would have to use the old compiler. - Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and implement SELECTED_REAL_KIND according to the Fortran standard. This would mean that people who put in a precision of 20 digits as a shorthand for REAL(KIND=16) will get the old version. This will lead to endless confusion, and penalize people who used SELECTED_REAL_KIND, so it should be avoided. - Support KIND=16 == IEEE_QP and KIND=15 = IBM_QP in the compiler, and have SELECTED_REAL_KIND return 16 for anything above double precision. This would actually violate the Fortran standard, and has been generally viewed by J3 as not a good idea. It would, however, work well for most users. Those who actually need IBM_QP would have to specify it specifically. - 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. Other opinions? Best regards Thomas