Re: [PATCH, version 2], Add support for _Float<N> and _Float<N>X sqrt, fma, fmin, fmax built-in functions

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 20 Oct 2017, Michael Meissner wrote:

> On Thu, Oct 19, 2017 at 10:15:44PM +0000, Joseph Myers wrote:
> > On Thu, 19 Oct 2017, Michael Meissner wrote:
> > 
> > >     1)	I switched to use DEF_EXT_LIB_BUILTIN to declare the _Float<N> and
> > > 	_Float<N>X functions.  This allows treating __builtin_sqrtf128 the same
> > > 	as sqrtf128.
> > 
> > It's not correct to do that unconditionally for all the existing 
> > DEF_GCC_FLOATN_NX_BUILTINS functions.  There should not be a public 
> > huge_valf128 function any more than a public huge_val function, just 
> > __builtin_huge_valf128.
> > 
> > Rather, you should add a new DEF_EXT_LIB_FLOATN_NX_BUILTINS.  It should be 
> > used by the new functions, and by the existing copysign / fabs / nan 
> > functions.  It should not be used by the existing huge_val / inf / nans 
> > functions.
> 
> Ok.  Would an initial patch to go back to using DEF_GCC_BUILTIN (which means
> people would need to use __builtin_sqrtf128 and __builtin_fmaf128) be
> acceptable, while I delve into the appropriate incantations to get it to work
> as desired be ok?

My argument was that *if* you provide __FP_FAST_FMAF128 (etc.), that 
should relate to an fmaf128 (etc.) built-in function.  If you don't define 
__FP_FAST_*, doing everything with DEF_GCC_BUILTIN would be reasonable as 
a starting point (with a view to moving selected functions to 
DEF_EXT_LIB_BUILTIN and defining __FP_FAST_* in a subsequent patch, and 
subject to calls still falling back to call the right external functions, 
e.g. sqrtf128 to deal with the errno-setting case of __builtin_sqrtf128).

-- 
Joseph S. Myers
joseph@codesourcery.com