From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20421 invoked by alias); 29 Jun 2018 17:15:44 -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 19647 invoked by uid 89); 29 Jun 2018 17:15:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Fri, 29 Jun 2018 17:15:00 -0000 From: Joseph Myers To: Florian Weimer CC: "Gabriel F. T. Gomes" , GNU C Library Subject: Re: Legacy _IO_* symbols and Flaot128 transition In-Reply-To: <1d310ac2-64f8-21d7-3bc5-2ddfa871f348@redhat.com> Message-ID: References: <20180629122600.1062b3bc@tereshkova> <1d310ac2-64f8-21d7-3bc5-2ddfa871f348@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-06/txt/msg01010.txt.bz2 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. > 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). 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 . (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.) -- Joseph S. Myers joseph@codesourcery.com