From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) by sourceware.org (Postfix) with ESMTPS id 02C423858407; Wed, 6 Oct 2021 17:39:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02C423858407 Received: by mail-vs1-xe35.google.com with SMTP id l22so1377012vsq.9; Wed, 06 Oct 2021 10:39:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ooRq9gcBdUxeTyhl1c30rhRUvCjLQgSOggzJejXh1IY=; b=3gd+nlsMyg2k2zZFzj94DHo2e7fKeMxXGC/DfGDnpGp8mzraaKD5zZNQZQov8KvvXh mm7TTEB0nLlGxE/PUG+95VGMiOM6AmBv81imAhydzFl5wjuH5PXAeeLQ2pCHCmYBM5tO x4mWHYLIr9fUmzkB7KnU6iQKh7RoJ6Tlx/boDQg6JoibD5arfEwoM3gDLNkeA5ByJf3G Q4YxXi+xEp+JSD5Fku1+xiX5smnJ/4wBpViqa+2hLQDpNqQtNF7lgGQNhoprYXM+VljQ 6jw+jNHiHkKajDDJhBBtiLEEBVOYdodE4p7N86kw60d4q37lGDvOVB3LCXw3q00KYM5H z0Ag== X-Gm-Message-State: AOAM530bor0XI/X5RcYWd4qU00Uh+zHlazv2IwOBlAyJ/qXgCF/RaWPH pUXKZx9qmm8M9nnCqybjyQFAHdBCBIrNH2H2svI= X-Google-Smtp-Source: ABdhPJytH2XN8SVvZjLSnAyOw8UqAn5NOr7OYjqcUjaciTDx3W4gD+p6+2M8YixcHAM0T234UqEJkL52Pf1KEqAquQg= X-Received: by 2002:a67:cb91:: with SMTP id h17mr9345241vsl.30.1633541949606; Wed, 06 Oct 2021 10:39:09 -0700 (PDT) MIME-Version: 1.0 References: <20211004100754.GL304296@tucnak> <20211004141410.GP304296@tucnak> <6d845542-536e-1a0f-70e9-d05eea98aae7@netcologne.de> <20211005215450.GC10333@gate.crashing.org> <90df1250-9b3f-4a55-bc67-e3e05e54f7ef@netcologne.de> <20211006151744.GE10333@gate.crashing.org> <20211006161910.GH10333@gate.crashing.org> In-Reply-To: <20211006161910.GH10333@gate.crashing.org> From: David Edelsohn Date: Wed, 6 Oct 2021 13:38:28 -0400 Message-ID: Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes To: Segher Boessenkool Cc: Thomas Koenig , Jakub Jelinek , GCC Development , Michael Meissner , Fortran List , Tobias Burnus , Jonathan Wakely Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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: Wed, 06 Oct 2021 17:39:16 -0000 On Wed, Oct 6, 2021 at 12:21 PM Segher Boessenkool wrote: > > On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote: > > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool > > wrote: > > > > > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > > > > On 05.10.21 23:54, Segher Boessenkool wrote: > > > > >>There is also the issue of binary data. If some user has written > > > > >>out data in double double and wants to read it in as IEEE quad, > > > > >>the results are going to be garbage. Another option for CONVERT > > > > >>might be the solution to that, or, as you wrote, having a > > > > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > > > > >>though. > > > > > > > > > >That means flipping the default on all PowerPC to no longer be double- > > > > >double. This means that you should have IEEE QP work everywhere, or the > > > > >people who do need more than double precision will have no recourse. > > > > > > > > I think we can exclude big-endian POWER from this - they do not have > > > > IEEE QP support, correct? So, exclude that from the SONAME change. > > > > > > Not correct, no. IEEE QP works fine in either endianness. > > > > This needs to be described with more granularity. IEEE QP > > instructions work with either endianness. > > > > IEEE QP is enabled and supported for PPC64 LE Linux on Power. The > > transition is under discussion. > > IEEE QP insns are enabled for BE as well: > > powerpc64-linux-gcc -Wall -W -O2 -S qp.c -mcpu=power9 > > === qp.c === > #define QP _Float128 > QP f(QP x) { return x*x; } > === > > results in > > .L.f: > xsmulqp 2,2,2 > blr > > > PPC64 BE Linux on Power does not define IEEE QP. The ABI could be > > updated and IEEE QP could be enabled, but PPC64 BE is not planning > > future releases from Linux distros. > > This is a different thing: on BE (and on LE by default as well) we use > double-double for long double. > > > IEEE QP for PPC64 FreeBSD on Power is an open question for the FreeBSD > > community. > > Yes. > > > AIX on Power will continue to use double-double long double format. > > GCC, LLVM, IBM Open XL and IBM XL compilers will continue to implement > > and support the double-double format on AIX. > > Yes. But this wasn't about what to use for long double -- it was about > Fortran even :-) > > The actual IEEE QP float types work fine on BE. I suspect they do on > AIX as well for that matter? > > Fwiw, with -mcpu=power8 we get > > .L.f: > mflr 0 > xxlor 35,34,34 > std 0,16(1) > stdu 1,-112(1) > bl __mulkf3 > nop > addi 1,1,112 > ld 0,16(1) > mtlr 0 > blr GCC can generate the IEEE QP instructions on AIX. The AIX Assembler is aware of the instructions. libquadmath is neither built nor installed on AIX. The AIX C library and AIX Math library are not aware of the IEEE QP type nor how to work with it, e.g., printf. Thanks, David