From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [89.1.8.213]) by sourceware.org (Postfix) with ESMTPS id 0B7273858400; Fri, 8 Oct 2021 22:55:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B7273858400 Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id 36D8E1249A; Sat, 9 Oct 2021 00:55:40 +0200 (CEST) Received: from [IPv6:2001:4dd7:2fa2:0:7285:c2ff:fe6c:992d] (2001-4dd7-2fa2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:2fa2: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 ECDC911D76; Sat, 9 Oct 2021 00:55:30 +0200 (CEST) Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes To: Iain Sandoe Cc: Jakub Jelinek , Michael Meissner , fortran@gcc.gnu.org, GCC Development , Tobias Burnus , Segher Boessenkool , David Edelsohn , Paul Thomas References: <20211004100754.GL304296@tucnak> <3dacfdf6-6b23-f307-969a-94265b506edb@netcologne.de> <20211007153306.GY304296@tucnak> <5533983c-f4d2-5041-75c9-9287e4e31f10@netcologne.de> <749ABCA1-5C3B-4EB8-8E4F-9B967A67AB07@googlemail.com> <334901cf-72b6-d1d7-dae6-3ec45170cf95@netcologne.de> From: Thomas Koenig Message-ID: Date: Sat, 9 Oct 2021 00:55:30 +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: ECDC911D76 X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Fri, 08 Oct 2021 22:55:43 -0000 Hi Iain, >> Things get interesting for user code, calling a routine compiled >> for double double with newer IEEE QP will result in breakage. > That would not happen with the proposal above, since the library would > have different entry points for the two formats. I meant the case where the user writes, with an old, KIND=16 is double double compiler, subroutine foo(a) real(kind=16) :: a a = a + 1._16 end subroutine foo and puts it in a library or an old object file, and in new code with an IEEE QP compiler calls that with real(kind=16) :: a a = 2._16 call foo(a) print *,a this will result in silent generation of garbage values, since Fortran does not mangle the function name based on it types. For both cases, the subroutine will be called foo_ (or MOD..._foo). There is no choice - we need to make object code compiled by the user incompatible between the old and the new format on the systems where we make the switch. This is starting to look like a can of worms from Pandora's box, if you pardon my mixed metaphors. Best regards Thomas