Boost logo

Boost :

From: John Maddock (jz.maddock_at_[hidden])
Date: 2019-10-15 17:05:17

>> 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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at