From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75250 invoked by alias); 7 Jun 2018 13:38:17 -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 74975 invoked by uid 89); 7 Jun 2018 13:38:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No 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=formats X-HELO: relay1.mentorg.com Date: Thu, 07 Jun 2018 13:38:00 -0000 From: Joseph Myers To: Tulio Magno Quites Machado Filho CC: , , Subject: Re: [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation In-Reply-To: <20180606223909.16675-5-tuliom@linux.ibm.com> Message-ID: References: <20180606223909.16675-1-tuliom@linux.ibm.com> <20180606223909.16675-5-tuliom@linux.ibm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-06/txt/msg00141.txt.bz2 On Wed, 6 Jun 2018, Tulio Magno Quites Machado Filho wrote: > Create a template for significand and reuse it in the ldbl-128ibm-compat > directory. The following applies to both this patch and the scalb one: I don't think it makes sense to have a template that is, in fact, only used for one format. If using a template for significand, I'd expect it to be used for all floating-point types / formats (removing the existing s_significand*.c etc. from math/ and sysdeps/ieee754/ldbl-opt/, listing it in gen-libm-calls instead of libm-calls). The empty version in sysdeps/ieee754/float128 would still ensure nothing gets built for significand for float128 and you'd still have the s_significandf128.c you add in this patch (the ChangeLog entry seems wrong to mention s_significandl.c). Using templates like that would mean the object files define excess aliases such as significandf32, but those aliases aren't in Versions files so they are harmless, not exported from libm. Much the same would apply to e_scalb templates. For w_scalb you'd need to treat the existing w_scalb*_compat templates like the other compat ones - that is, make their entire contents conditional on LIBM_SVID_COMPAT (so they don't get built for new targets or static linking at all), while the new w_scalb template would be listed in gen-libm-calls and not have any LIBM_SVID_COMPAT conditionals in it, and a new dummy sysdeps/ieee754/float128/w_scalbf128.c would ensure no code actually gets built from that template in the normal float128 case. Given the general handling of finite aliases I'd expect a new __scalbf128_finite function export to be added to the Versions file for ldbl-128ibm-compat as well. I would suggest that patches adding such templates and using them for existing formats without changing the ABI anywhere (a cleanup / refactoring of existing code) be separated from patches that actually add new ldbl-128ibm-compat symbols. -- Joseph S. Myers joseph@codesourcery.com