Re: [PATCH] Move M_DECL_FUNC_R* to math-type-macros.h

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 11 May 2018, Tulio Magno Quites Machado Filho wrote:

> > (In any case, no new *ibm128_finite 
> > symbols should be added, because exported implementation-namespace libm 
> > functions are always once-per-format so you shouldn't need to add any more 
> > other than for obsolescent functions provided for long double but not 
> > float128.)
> 
> In this case, how would users continue to use IBM long double finite functions?

They'd compile with -ffinite-math-only -mabi=ibmlongdouble, which would 
result in *l calls being redirected to __*l_finite.  Whereas compiling 
with -ffinite-math-only -mabi=ieeelongdouble would result in *l calls 
being redirected to __*f128_finite (which already exist, so no new symbols 
are needed there at all except I suppose __scalbf128_finite).

You need to change how math.h defines some macros for including 
bits/math-finite.h to achieve the above, but you don't need to add any new 
*_finite exports (other than __scalbf128_finite) because those are 
implementation-namespace exports, so one per format not one per type (and 
even if you add new *l symbol versions for public functions, which I don't 
think is necessary but you may have a case for based on what you've tried 
for later patches in the series, that definitely shouldn't be done for 
these implementation-namespace functions).  Likewise no new variants of 
functions such as __issignaling* are needed; just make __MATH_TG do the 
right thing (I *think* the internal uses of __MATH_TG within libm in 
math-underflow.h, which currently expect suffixes used by __MATH_TG to be 
those for the types for the current compilation, should in fact still work 
without needing changing).

-- 
Joseph S. Myers
joseph@codesourcery.com