On Friday, 8 August 2025 11:21:10 Pacific Daylight Time Paul Caprioli via Std-
Proposals wrote:
> Supposing that double is IEEE-754 binary64 and ptr has type double*, is it
> safe to reinterpret_cast<std​::​float64_t*>(ptr) and then use it to read or
> modify memory that is an array of doubles? I could not find that this is
> allowed, so I would like to float the idea for such a proposal.

I think we need to understand why you want to do that first. Because:
 
> For
> example, on Apple hardware I might want to use intrinsics from arm_neon.h,
> which has typedef __fp16 float16_t; and provides vld1_f16(const float16_t
> *). Given const std::​float16_t* ptr, is it safe to use
> vld1_f16(reinterpret_cast<const float16_t*>(ptr)) ?

If you're using intrinsics, you've stepped beyond the Standard. You're on very
machine-specific content and you rely on your compiler implementation. At that
point, you *know* what the hardware behaviour is.

Therefore, I'd say that if the above works on your hardware, it's allowed.

> Note that the __fp16 data type is not an arithmetic data type. The __fp16
> data type is for storage and conversion only. Arm recommends that for new
> code, you use the _Float16 data type instead of the __fp16 data type.
> __fp16 is an Arm C Language Extension.

And IIRC there were two different and incompatible formats for FP16, one of
them not what the IEEE 754 standardised.
 
> I'm wondering whether the standard does/can/should say anything about
> reinterpret_cast between _Float16* and __fp16* and using the resulting
> pointer to read or modify memory.

Since __fp16 is not in the Standard, the Standard says absolutely nothing.
It's an implementation-specific type and you need to read your implementation's
documentation.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering