This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation
Joseph Myers <joseph@codesourcery.com> 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