id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
6459	long double functions not built on Linux ARM	Petr Machata <pmachata@…>	John Maddock	"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."	Bugs	closed	To Be Determined	TR1	Boost 1.48.0	Problem	fixed