RE: Macros using __NO_LONG_DOUBLE_MATH

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 8 Jun 2015, Wilco Dijkstra wrote:

> > I don't see how such a change would benefit using GCC built-in functions
> > anyway.  Presumably you'd do
> > 
> > # if __GNUC_PREREQ (6, 0)
> 
> I'm using __GNUC_PREREQ (4, 4) && !defined __SUPPORT_SNAN__ to enable 
> inlining - better to have inlining even if it isn't 100% optimal rather 
> than no inlining and having to go through the PLT to call a 
> 4-instruction function...

Do you have at least microbenchmarks to confirm the existing GCC inline 
expansions are better than the glibc out-of-line calls?  Such 
microbenchmarks should preferably go in glibc's benchmark suite.

Logically glibc should be built with -fsignaling-nans, but it's possible 
we get away without that in most cases (as in: most functions *should* 
raise "invalid" for signaling NaN operands, so an implementation of is* 
that spuriously raises that for signaling NaNs wouldn't actually cause 
problems, and we may not rely on avoiding optimizations that are invalid 
for signaling NaNs).  Of course some issues could be covered up by lack of 
test coverage (and at least tests of signaling NaNs ought to be built with 
that option).

> > (b) You'd only use the GCC built-in functions when guaranteed to expand
> > inline rather than to an external function call - so, when using them, you
> > don't need to worry about whether the corresponding external function
> > exists or not.
> 
> They are always inlined, even with -O0 and fno-builtin.
> 
> However what to do with the odd 128-bit IBM long double format? Is it dead
> or still used? Currently __copysignl uses the builtin internally which would

It is used (and unfortunately the work to use IEEE binary128 for 
powerpc64le wasn't done in time to avoid IBM long double being used there 
as well).

> only update one of the 2 signs... If GCC doesn't understand the format then

Rather, target-independent inline copysign punts when signbit_rw is -1, so 
it isn't expanded inline at all.

> isinf, isnormal, isfinite would likely be incorrect as well as these need
> the right LDBL_MIN/MAX value.

GCC understands the format to the extent of treating it for most purposes 
as a fixed-width 106-bit mantissa (which is also the extent to which 
glibc's libm tests and strtold understand it).  It's true that copysignl 
is not expanded inline for it in certain cases (GCC bug 58797), and that 
fabsl is expanded inline incorrectly for it in certain cases (GCC bug 
29253, hence sysdeps/powerpc/nofpu/Makefile using -fno-builtin-fabsl on 
affected files).

Strictly, the largest finite long double value has 107 bits (53 1s, 0, 53 
1s) and is not representable in 106 bits, and so such a value would be 
misinterpreted by GCC's inline is* as infinite (the proper way of inlining 
isinf / isfinite being to check the top double only) - given the other 
problems with such values, it's not clear it's useful for glibc to try 
working around this particular GCC issue.  GCC does properly handle 
LDBL_MIN being greater than DBL_MIN, however.

-- 
Joseph S. Myers
joseph@codesourcery.com