This adds some extra instrumentation to bessel_j0.hpp, everything else are fixes for the test programs.
The advantage of testing on this platform is that it has a true 128-bit long double which is a good test of our assumptions in code.
Include an "escape macro" so thread safety can be disabled if certain bernoulli features are to be used in a no-atomics environment.
Fixes https://github.com/boostorg/math/issues/673.
* Fix comment typos: "endinaness" to "endianness"
* Change the C++20 checks (for both `__cplusplus` and `_MSVC_LANG`)
to be strict: `> 202000L` to `>= 202002L`
* Add an `#error` when C++20 `<bit>` is missing, just in case.
* Fix the `_WIN32` definitions. All Windows platforms are little-endian
(regardless of x86/x64/ARM/ARM64), `<boost/predef/other/endian.h>`
correctly reports little-endian, and MSVC's STL simply hardcodes
`enum class endian { little = 0, big = 1, native = little };`, see
f75c7f596c/stl/inc/bit (L271) .
* Add a `static_assert` to verify that exactly one of
`BOOST_MATH_ENDIAN_BIG_BYTE` or `BOOST_MATH_ENDIAN_LITTLE_BYTE` is
true. This avoids the need for "Endian type could not be identified"
consistency checks below.
* Fixboostorg/math#677 by not testing `BOOST_MATH_ENDIAN_BIG_BYTE` and
`BOOST_MATH_ENDIAN_LITTLE_BYTE` with the preprocessor, as
`std::endian::native` isn't a preprocessor constant. Now, this simply
expects `BOOST_MATH_ENDIAN_BIG_BYTE` to be usable in a constant
expression, and assumes (due to the consistency check above)
that if we aren't big-endian, we must be little-endian.
* Initial commit
* Move error handling to impl
* Validate tests for float
* Test other types
* Add tests for types that are convertible to int
* Add include test
* Update docs
* Add fabs overloads
* Add fabs to docs
* Add missing header to tests
* Fix for old versions of clang and cleanup naming conventions
* Update jamfile
* Add glibcxx constexpr cmath tests and fix docs
* Use equality in testing instead of tolerance
