Allow fallthrough of Android to 128-bit float

[mborland]

Closes: #1389

[Martchus]

I noticed the same problem in my Android builds and came up with basically the same minimal fix.

However, I'm wondering whether it would make more sense to determine the floating point format using LDBL_MANT_DIG instead of making assertions on what that value is for each and every platform. This is actually already done further down in that file (#elif (LDBL_MANT_DIG == 113)) where the assertion (static_assert(LDBL_MANT_DIG == 113) is then completely redundant. There's also #elif defined(__GNUC__) && (LDBL_MANT_DIG == 106) further down which also uses LDBL_MANT_DIG and even already avoids redundant assertions.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.35%. Comparing base (df8bb08) to head (74406e5).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #1390   +/-   ##
========================================
  Coverage    95.35%   95.35%           
========================================
  Files          825      825           
  Lines        68203    68203           
========================================
+ Hits         65033    65034    +1     
+ Misses        3170     3169    -1     

Files with missing lines	Coverage Δ
.../boost/math/special_functions/detail/fp_traits.hpp	100.00% <ø> (ø)

... and 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update df8bb08...74406e5. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mborland]

I noticed the same problem in my Android builds and came up with basically the same minimal fix.

However, I'm wondering whether it would make more sense to determine the floating point format using LDBL_MANT_DIG instead of making assertions on what that value is for each and every platform. This is actually already done further down in that file (#elif (LDBL_MANT_DIG == 113)) where the assertion (static_assert(LDBL_MANT_DIG == 113) is then completely redundant. There's also #elif defined(__GNUC__) && (LDBL_MANT_DIG == 106) further down which also uses LDBL_MANT_DIG and even already avoids redundant assertions.

I was thinking the same thing. Now that we assert the value of LDBL_MANT_DIG at each point we might as well use that information exclusively so we don't end up like the current situation on different platforms. If the value is missing or an unexpected value, that should be our only point of assertion.

[Martchus]

Nice, that's what I had in mind.

[mborland]

@jzmaddock do you have any opinions on this reorganization? I left in the special cases that we have no way of testing (e.g. Motorola 68000k)

[jzmaddock]

I confess I was thinking of making much the same changes - it looks logical to me - however, I guess the question is do we have say 64-bit (long) doubles which are not in IEEE format, and will therefore cause the code logic to fail? This is old code that we inherited, and was reviewed in it's own right as I recall, the intention was to select for platforms with known bit-layouts, the newly added static_asserts were supposed to just be a quick sanity double check that all was well. So that worked well then!

[mborland]

I confess I was thinking of making much the same changes - it looks logical to me - however, I guess the question is do we have say 64-bit (long) doubles which are not in IEEE format, and will therefore cause the code logic to fail? This is old code that we inherited, and was reviewed in it's own right as I recall, the intention was to select for platforms with known bit-layouts, the newly added static_asserts were supposed to just be a quick sanity double check that all was well. So that worked well then!

The only mainstream non-IEEE long double I am aware of that's still floating around is ibm128 on PPC64, and the newer operating systems are migrating those to the proper float128. There could be some complete odd ball system out there, but I think it's best to wait for a bug report from them to explain what's going on with their system.