Regarding reinterpret_cast between double* and std​::​float64_t*, the thought is how best to write code that uses two third-party libraries, each of which has made a different choice regarding the type for their IEEE-754 binary64 pointers. I expected that the standard would not involve itself in implementation-dependent types such as __fp16. However, since both GCC and Clang support neon intrinsics on Arm hardware, it might not be unreasonable for the standard to provide a recommended practice, especially for a type that is bit-identical to a standardized floating-point type (e.g. std::float16_t). I did not find guidance in either GCC's or Clang's documentation as to whether using reinterpret_casted pointers is safe between std::float16_t and __fp16. If someone knows better, I would be grateful for guidance. By the way, I believe the non-IEEE 16-bit floating point type was made deprecated/obsolete by ARM. In any case, this email thread is intended to consider only the IEEE floating-point format. Thanks, Paul -----Original message----- From: Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Sent: Friday, August 8 2025, 2:09 pm To: std-proposals_at_[hidden] <std-proposals_at_[hidden]> Cc: Thiago Macieira <thiago_at_[hidden]> Subject: Re: [std-proposals] TBAA and extended floating-point types 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 -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals