From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98795 invoked by alias); 2 Jul 2018 07:22:11 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 98781 invoked by uid 89); 2 Jul 2018 07:22:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=POWER, H*i:sk:alpine., lie, configurations X-HELO: mx1.redhat.com Subject: Re: Legacy _IO_* symbols and Flaot128 transition To: Joseph Myers Cc: "Gabriel F. T. Gomes" , GNU C Library References: <20180629122600.1062b3bc@tereshkova> <1d310ac2-64f8-21d7-3bc5-2ddfa871f348@redhat.com> From: Florian Weimer Message-ID: Date: Mon, 02 Jul 2018 07:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00004.txt.bz2 On 06/29/2018 07:15 PM, Joseph Myers wrote: > On Fri, 29 Jun 2018, Florian Weimer wrote: > >>> Should they be turned into compat symbols *because* they won't be >>> installed headers (and we don't want new user code linking against them)? >>> Or is there something else to it? >> >> No, it's just a cleanup, and to clarify what's necessary for future work. > > Anything not accessible from installed headers is a good candidate for > making into a compat symbol. Agreed. >> I also want to add some minimal test for libnldbl_nonshared.a, and reducing >> its size helps with that. (I'm aware that on ppc64, the current toolchain >> doesn't support long double as double anymore, but I can just lie to the >> compiler and use double instead, I guess.) > > It certainly appears to be supported to me (using GCC mainline, compiling > with -mlong-double-64 produces sizeof (long double) == 8 for both > powerpc64 and powerpc64le). Oh, this option isn't documented for POWER, so I didn't try it. > However, libnldbl_nonshared.a is for long double = double *with compilers > not supporting asm redirection*. Which is a case the (incorrect) patch in > provides > evidence hasn't worked for a long time. So I still think there's a case > for eliminating libnldbl_nonshared.a and explicitly requiring asm > redirection support for these non-default long double variants, which it's > in practice required already (if not more generally requiring it for any > compiler using the glibc headers), as discussed in > . Okay, I review the situation to determine which way is the best way forward for the 2.28 release. > (The actual __nldbl_* exports from the glibc shared libraries - the > functions that get used with -mlong-double-64 given asm redirection > support - *should* be tested, via building some tests with > -mlong-double-64. The binary128 work should, as per > , add tests > that are generic to different long double formats, so that it will then be > easy to build them for -mlong-double-64 for ldbl-opt configurations.) I suppose we should also add tests for the functions which are not redirected to __nldbl_* variants, but to the non-l variants (because only for things like printf, separate wrappers are needed if there is redirection support). Thanks, Florian