long double functions not built on Linux ARM

[Petr Machata <pmachata@…>]

On Linux on ARM (with GNU libc in any case), the semantics of NO_LONG_DOUBLE_MATH seem to be that there's no distinct bit width for variables of long double type. The prototypes of impacted functions (asinhl etc.) are still visible, but they are aliased to their "plain" variant. The syntax for "long double" was present since the first version of both C and C++ standards, so the prototypes are just always visible, and NO_LONG_DOUBLE_MATH only determines whether long double has a distinct bit width, i.e. whether a distinct set of _implementations_ is necessary.

On boost side, BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS seems to be defined on targets where compiler or system libraries are buggy or the syntax is missing altogether, but it's apparently also used in the same sense as above ("Dinkumware's std C lib doesn't have true long double precision").

I don't think it is right to omit long double functions just because long double doesn't provide the extra accuracy. I understand that you would want to skip this on targets where stuff gets miscompiled or similar. But ARM implementation is correct, it just happens to have "double" and "long double" of the same length. The code using long double can be compiled and works as expected. It seems correct to simply ignore the value of NO_LONG_DOUBLE_MATH and build long double functions unless it's known-broken.

It's possible that I don't see some other motivation, but I didn't really find much data about this. FWIW, the test_tr1.cpp passes on ARM.

[John Maddock]

(In [76764]) Don't be too quick to disable long double functions if NO_LONG_DOUBLE_MATH is set by GLIBC. Fixes #6459.