Fix rounding for non-representable numbers

[mborland]

Partially addresses re-raised #430. Once CI validates this fix works for llround will propagate to the rest of the functions.

[mborland]

@jzmaddock any idea why this would break the use of pre-compiled headers under MSVC? See: https://github.com/boostorg/math/actions/runs/4447933117/jobs/7810069256?pr=968#step:11:523

[jzmaddock]

any idea why this would break the use of pre-compiled headers under MSVC?

No... I wonder if there are any unrelated changes effecting us - build system?

BTW I can't help thinking there may be a simpler solution, let me have a think.

[mborland]

The failure is now 9223372036854775807.5 cannot be represented as the target type. I assume this would be dependent on rounding mode but the default will be 9223372036854775808 which is greater than LLONG_MAX.

[jzmaddock]

Ah.... the test case is wrong: it assumes that the boundary case on 2^d where there are d digits in the long long is always an integer, as is float_prior of that value. That will hold as long as there are fewer digits in the floating point type than the integer, but not otherwise (long double in this case).

So... I guess either only test floats that have fewer digits than the integer type - since that is the bug case - or else we need to figure out how to fix the test case. The latter might be tricky, since we're basically duplicating the functionality of llround to carry out the test! So I'd favour the former for now?

[mborland]

The PCH issues are likely related to recent changes in B2. I have opened an issue with them: bfgroup/b2#229

[mborland]

@jzmaddock Can you take a look at this now that it's green? The context switching for constexpr calculation is more verbose than I had hoped.

[jzmaddock]

Thanks for this Matt: other than the two minor comments looks good to me!