Re: [PATCH 4/9] ldbl-128ibm-compat: Add a generic significand() implementation

[Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>]

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