From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 5CA893858433; Tue, 5 Oct 2021 21:53:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5CA893858433 Received: by mail-wr1-x42c.google.com with SMTP id j8so2215632wro.7; Tue, 05 Oct 2021 14:53:34 -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=feoeDPS089FgRslAI9EhKeqFcK+RxTUNyRSmXdB68jY=; b=ot4lvY///LlAkFCmaVJkmeAAP97K9EwA/0B3jZNxfYZVtGoytO6Fa0Y+gko4FXW67H gsQmUpP6TG8WmcuSHB4MbonqyRscbRQ9SrXwKj4NlRpQdbIK7ZrRu4UQGWxVTI4mL7z8 O+PjRniUgbYg0i36eGLlcYqjG24BLrKU8vegyVAd/EWJxC674fcnY7su3KSDcu9yAZet DNH6vPI3NSNtXxNWyg5RGekU8ejFKQwg5wy08tjrN4UhpT5VrcBgFAIVQCbUiUe7KYU6 dmIxod2R8X76iI7qV2DFnSYo6Me04ugmq0o0V5nluuF+ai+jTmAMG1I6hUQOsKOehf/c yPPQ== X-Gm-Message-State: AOAM532/K1y8TT9+NKMMmDntp6fubYnXTZKaId0mWGHvjOI3XXx1SMSe F5qDb4wpa8lrps3ad+yGpgiTj/ZzDx41bz2brF0= X-Google-Smtp-Source: ABdhPJy1zfJ8ZGhh1yfUhbkqfBYWAP8+zldhnePkDH/uV8pJzUhBipgcOyoxIS76CVUqGonwqJFV03LPoiyDwXo+e5A= X-Received: by 2002:a7b:cb04:: with SMTP id u4mr6004737wmj.176.1633470813459; Tue, 05 Oct 2021 14:53:33 -0700 (PDT) MIME-Version: 1.0 References: <20211004100754.GL304296@tucnak> <20211004141410.GP304296@tucnak> In-Reply-To: <20211004141410.GP304296@tucnak> From: Jonathan Wakely Date: Tue, 5 Oct 2021 22:53:22 +0100 Message-ID: Subject: Re: libgfortran.so SONAME and powerpc64le-linux ABI changes To: Jakub Jelinek Cc: "fortran@gcc.gnu.org List" , "gcc@gcc.gnu.org" , Tobias Burnus , Segher Boessenkool , Michael Meissner , Jonathan Wakely X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 05 Oct 2021 21:53:38 -0000 On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc, wrote: > On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote: > > 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. > > 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. > > 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?). > > > > Your thoughts on this? > > Based on some IRC discussion, yet another option would be bump libgfortran > SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean > always IEEE quad (starting with GCC 12) and if wanted add support for > real(kind=15) meaning double double. > libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to > make > sure that regardless of the long double choice for C/C++ (whether default > configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128 > long double. > One problem with that is that I think IEEE quad long double support relies > on glibc 2.32 or later, so not sure what exactly would be done if gcc is > built against older glibc when it needs to call libm routines. Perhaps > convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss > of precision and range, but at least something). > > What does libstdc++ do there? All the new ieee128 support in libstdc++ is dependent on being built against a new glibc. If you don't have a new glibc, you wish don't get any C++ library support for ieee128. The SONAME doesn't change, but there are additional symbols versions (and symbols) present in libstdc++.so.6 if built against a new glibc. > >