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 jos...@codesourcery.com
