Re: [PATCH 6/9] Remove the error handling wrapper from exp and exp2

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 29 Jun 2018, Szabolcs Nagy wrote:

> ok so the reason i used *_double_other is to avoid affecting
> long double symbols, now i see that i either have to introduce
> new symbol version for expl or keep the long double wrappers
> somehow for targets where long double is the same as the double.
> 
> so is it acceptable to keep expl wrappers but remove exp
> wrappers on the affected targets? what's the best way to do this?
> customize sysdeps/ieee754/dbl-64/w_exp.c to do the right thing?

The following applies generically regardless of whether you have a new 
expl symbol version: expl compat symbols for long double = double for 
ldbl-opt configurations need to keep pointing to the w_exp_compat version 
supporting SVID error handling.  (For exp2l, however, the ABI bug meaning 
that symbol only got added in GLIBC_2.4 means such compat symbols don't 
exist and those configurations only have exp2l for long double != double. 
The automatically-generated definitions of 
LONG_DOUBLE_COMPAT_CHOOSE_libm_exp2l etc. depend on LONG_DOUBLE_COMPAT in 
appropriate ways to allow code to do different things depending on whether 
such a compat symbol should be present - powerpc64le being a case where 
-mlong-double-64 is supported but none of those compat symbols exist 
because the first glibc version for the port already supported 128-bit 
long double.  Those macros are duly used in the ldbl-opt version of 
libm-alias-double.h.)

If you keep expl using the wrapper (rather than adding a new version of 
it), then of course on existing platforms with long double = double (as 
the current ABI) that means expl in shared libm needs to support SVID 
error handling, so needs to be defined by the wrapper from w_exp_compat.  
Whereas for new ports with long double = double (both NDS32 and C-SKY 
being under preliminary review, though without upstream tools yet being 
ready), and likewise for static linking, there is no need for SVID error 
handling support, w_exp_compat generates no code and so the expl symbol 
needs to be generated from w_exp (or e_exp).

I think the effect of the above may be that the various 
libm_alias_double_r definitions need refactoring so there is a macro that 
just does the (possibly empty) long double aliasing parts, which would 
then be used in the w_* files (while the _other macro would be used in the 
e_* files to create the _FloatN / _FloatNx aliases, which never need any 
support for SVID error handling and so can always avoid the wrappers once 
you have integrated errno setting).

Optimally, but probably more complicated, you *would* have a new expl 
symbol version that avoids the wrappers on platforms where long double = 
double is the current ABI, with the old one becoming a compat version in 
w_exp_compat.  Then, dbl-64 w_exp would remain empty and not generate any 
code, but w_exp_compat would need to handle defining the old expl as a 
compat symbol in long double = double cases.

-- 
Joseph S. Myers
joseph@codesourcery.com