stillwater-sc / universal / 31735982700

85%

master: 84%

push

github

fix(takum): correct conversion from long double (#1307)

takum<>::convert_ieee754() read the source's IEEE 754 fields and then forced
double's bias and fraction width whenever the source was a long double, on the
stated assumption that extractFields() routes long double through double.

It does that only when LONG_DOUBLE_DOWNCAST is defined.  Everywhere else --
Linux and macOS x86-64 with gcc or clang, so most of the CI matrix -- it returns
genuine x87 80-bit fields, whose exponent is biased by 16383 rather than 1023.
Read with double's bias, the unbiased exponent came out around 15361, past
max_characteristic() by four orders of magnitude, and the conversion saturated:

    takum<32,3> x = 3.0L;        // 5.7896e+76, i.e. maxpos
    takum<32,3> y; y = 1.0L;     // maxpos
    takum<32,3> z{ (long double)takum<32,3>{3.0} };   // maxpos

EVERY finite long double converted to +/-maxpos, through the constructor, the
assignment operator, and any round trip.  The outbound direction was correct,
which made the round trip the sharpest form: a value went out intact and came
back as maxpos.  takum_log<> is unaffected -- its conversion works from
std::log() rather than from extracted fields.

Fixed by narrowing to double before extraction.  A long double is not one
format: x87 80-bit on x86 with an explicit rather than implicit integer bit,
IEEE binary128 on ARM64, plain double on MSVC.  Decoding three layouts is not
worth it here; taking the platform's own conversion costs the bits beyond
double's 53, and the alternative was a wrong answer.  The dead branch in
convert_ieee754() is replaced by a static_assert, so a future caller that passes
a long double gets a compile error naming the requirement rather than silent
saturation.

The reason this survived 11 platforms is that no test converted from a long
double.  static/tapered/takum/conversion/native_float.cpp is therefore organised
by TYPE rather than by value: for float, double and long double, against both
va... (continued)

4 of 4 new or added lines in 1 file covered. (100.0%)

42123 of 49337 relevant lines covered (85.38%)

7214545.98 hits per line