From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:1]) by sourceware.org (Postfix) with ESMTPS id 3AFB63858D39; Fri, 8 Oct 2021 16:26:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3AFB63858D39 Received: from cc-smtpin3.netcologne.de (cc-smtpin3.netcologne.de [89.1.8.203]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 66F2F125FA; Fri, 8 Oct 2021 18:26:20 +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-smtpin3.netcologne.de (Postfix) with ESMTPSA id 8580311DF0; Fri, 8 Oct 2021 18:26:02 +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> From: Thomas Koenig Message-ID: <334901cf-72b6-d1d7-dae6-3ec45170cf95@netcologne.de> Date: Fri, 8 Oct 2021 18:26:02 +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: <749ABCA1-5C3B-4EB8-8E4F-9B967A67AB07@googlemail.com> 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: 8580311DF0 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, 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 16:26:23 -0000 Hi Iain, > If one wanted to prioritize library SO name stability - then, perhaps, the > approach Jonathan mentioned has been used for libstdc++ (add new > symbols for ieee128 with a different mangling to the existing r/c_16 ..) > would be preferable (the FE then has to choose the relevant symbol/ > mangling depending on target). That's not all that would have to be changed. Consider write (*,*) 1.0_16 end program which is translated (using -fdump-tree-original) to _gfortran_st_write (&dt_parm.0); { static real(kind=16) C.3873 = 1.0e+0; _gfortran_transfer_real128_write (&dt_parm.0, &C.3873, 16); } _gfortran_st_write_done (&dt_parm.0); so we actually pass a separate kind number as well (why, I'm not sure). We would have to go through libgfortran with a fine comb to find all the occurrences. Probably some m4 hackery in iparm.m4 and ifunction.m4. So, doable from the library side, if some work. Things get interesting for user code, calling a routine compiled for double double with newer IEEE QP will result in breakage. We cannot use the KIND number to differentiate, because we must assume that people have used KIND=16 and selected_real_kind(30) interchangably, and we certainly do not want to nail people to the old double double precision on hardware for which IEEE QP is available. So, KIND=15 for IEEE QP is out. It's not an easy problem, unfortunately.