From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11563 invoked by alias); 15 Jun 2018 20:16:27 -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 8764 invoked by uid 89); 15 Jun 2018 20:15:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,TIME_LIMIT_EXCEEDED,URIBL_RED autolearn=unavailable version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com From: Tulio Magno Quites Machado Filho To: Joseph Myers Cc: libc-alpha@sourceware.org, gabriel@inconstante.eti.br, raji@linux.ibm.com Cc: Subject: Re: [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation In-Reply-To: References: <20180606223909.16675-1-tuliom@linux.ibm.com> <20180606223909.16675-5-tuliom@linux.ibm.com> User-Agent: Notmuch/0.25 (http://notmuchmail.org) Emacs/25.3.1 (x86_64-redhat-linux-gnu) Date: Fri, 15 Jun 2018 20:16:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18061520-0064-0000-0000-0000031BCD44 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009197; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000265; SDB=6.01047466; UDB=6.00536546; IPR=6.00826440; MB=3.00021672; MTD=3.00000008; XFM=3.00000015; UTC=2018-06-15 20:15:05 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18061520-0065-0000-0000-0000399B5B9D Message-Id: <87wouzbyd6.fsf@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-15_11:,, signatures=0 X-SW-Source: 2018-06/txt/msg00445.txt.bz2 Joseph Myers writes: > 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. Ack. > Much the same would apply to e_scalb templates. Ack. > For w_scalb you'd need to > treat the existing w_scalb*_compat templates like the other compat ones - I didn't follow completely your proposal here. Are you saying that ldbl-128ibm-compat also needs a w_scalbf128_compat? > 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. Ack. > 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. Indeed. > 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. OK. I'm going to split both. -- Tulio Magno