It's also good to remember that IEEE floating-point was specifically
designed such that doing an integer increment on the bitwise representation
produces the next higher floating-point value. TBAA is for the birds and
the optimizationists.

On Fri, Aug 8, 2025 at 2:59 PM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> In my opinion, I as a programmer shouldn't have to deal with
> __floating_point types of any kind.
> doubles and floats are annoying as it is and I'm extremely happy that when <stdfloat>
> is implemented I don't have to touch them ever again.
>
> When I want a uint32_t I want an unsigned integer with 32 bits of
> precision because it fits the target problem I want to solve. I don't want
> to use an unsigned int and play the game of russian roulette depending on
> which compiler/target platform combination the code was compiled and end up
> with "whatever"...
>
> You have 4 base completely distinct integer types, short, int, long, and
> long long. But they can only be one of 3 sizes 16, 32, or 64bit... yeah
> int8_t can not be made with one of those (it's a signed char, as in a
> character)...
>
> I want a 32bit IEEE 754 floating point and have it behave as such, not
> whatever a "float" just happens to be on a particular platform.
>
> I see no reason why these well-defined types shouldn't just be the
> standard types (no additional headers required), and if your platform has
> some other wishy-washy type then put that in a system specific library
> (that I don't want too ever look at or care that it exists).
>
> But that's just me.
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Friday, August 8, 2025 8:21:18 PM
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Cc:* Paul Caprioli <paul_at_[hidden]>
> *Subject:* [std-proposals] TBAA and extended floating-point types
>
> Type-based aliasing analysis (TBAA) enables desirable optimizations, so
> it's generally undefined behavior to read or modify memory through a
> pointer to a different type.
> The standard specifies when the result of reinterpret_cast can be used to
> access memory.
> For example, for any object z of type std::complex<T>,
> reinterpret_cast<T(&)[2]>(z)[0] is the real part of z.
>
> 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'm not sure whether the standard does/can/should say anything about
> implementation-specific types representing floating-point values.
> 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)) ?
>
> 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.
>
> Also, the C++ standard has Recommended practice: Any names that the
> implementation provides for the extended floating-point types described in
> this subsection that are in addition to the names declared in the
> <stdfloat> header should be chosen to increase compatibility and
> interoperability with the interchange types _Float16, _Float32, _Float64,
> and _Float128 defined in ISO/IEC TS 18661-3 and with future versions of
> ISO/IEC 9899.
>
> 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.
>
> Regards,
> Paul
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>