-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std::float16_t/std::bfloat16_t support #148
Comments
This is very reasonable and we will add (and test) such support as soon as mainstream compiler releases support C++23. At the moment, it looks like GCC 13 is not yet released. |
That's right, new GCC versions are usually released around April or May each year. |
GCC 13 is now widely available. |
I have begun the work but I am not yet getting a clean build. |
I have taken your branch and rebased it and it looks good. Just some tests left. Maybe |
I didn't understand how to incorporate #264 to use a rebased branch with your initial work. Anyway, I pushed and it's looking good haven't checked why though. I built and tested system info:
FASTFLOAT_CONSTEXPR_TESTS='1'
FASTFLOAT_64BIT_LIMB='1'
little endian
FASTFLOAT_64BIT='1'
FLT_EVAL_METHOD='0'
_WIN32='1'
_WIN64='1'
fegetround() = FE_TONEAREST
...
[doctest] test cases: 27 | 27 passed | 0 failed | 0 skipped
[doctest] assertions: 8993 | 8993 passed | 0 failed |
[doctest] Status: SUCCESS! The tests in One test is failing:
|
@dalle I don't trust the testing code I wrote for 16-bit floats. :-) We need to examine these tests manually and make sure it makes sense. It is likely incomplete as well. (Thankfully, it should not be enormously difficult to get it right since GCC already supports those on top of fast_float.) |
@dalle Feel free to open a new PR even if it is only partial progress. |
Just FYI, in GCC we've added support for from_chars for the C++23 std::{,b}float16_t support in https://gcc.gnu.org/r13-3592 .
We've done it by using an artificial wrapper class for each of those and by using float as container type on the library boundary so that
we don't need to change library ABI whenever some new architecture decides to start supporting those formats.
But if you'd want to have direct support for these types in upstream, it could be a matter of:
And add specializations for {min,max}_exponent_fast_path, max_mantissa_fast_path and exact_power_of_ten (those we didn't need for GCC because we've omitted for these the Clinger's fast path).
The text was updated successfully, but these errors were encountered: