Strange complexity within Arm: "The ARM target provides hardware support for conversions between __fp16 and float values as an extension to VFP and NEON (Advanced SIMD), and from ARMv8-A provides hardware support for conversions between __fp16 and double values. GCC generates code using these hardware instructions if you compile with options to select an FPU that provides them; for example, -mfpu=neon-fp16 -mfloat-abi=softfp, in addition to the -mfp16-format option to select a half-precision format."
Unpleasant, sorry. I really, really don't wish to know all that! 😉 Paul
Me neither. My first reaction was "yes of course we should do that", but on reflection I'm not so sure: The intention of <boost/cstdmath.hpp> was to provide a *portable* set of typedefs such that each is mapped to the corresponding IEEE defined type. And indeed, if numeric_limits<float32_t>::is_iec559 happens to be false, then the header will trigger a static_assert and complain that it's incorrectly configured. So... we could provide a float16_t typedef, but if we're being consistent (and we should be), then it would only be for IEEE float16 compatible types. My concern is quite how we detect/configure/test that. I also don't think we currently have any tester running on arm (for example), and we certainly don't have arm CI (is there any?). Mostly thinking out loud yours, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus