> I know ieee-754 is from 1985 and nearly everyone uses it and thus double
is for paractial purposes ieee-754, but are we forcing that

Arduino Uno and Atmega-based devices are prominent examples where double is
a 32 bit float.[1] I believe this is because they do not have a 64-bit FPU.
Same with avr-gcc.[2] Can we reinterpret_cast double to a float32_t on
these platforms?

[1]
https://docs.arduino.cc/language-reference/en/variables/data-types/double/

[2] https://gcc.gnu.org/wiki/avr-gcc

On Tue, Aug 26, 2025, 3:49 p.m. Paul Caprioli via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> > On Mon, Aug 25, 2025, at 23:19, Paul Caprioli via Std-Proposals wrote:
> > > Given std::vector<double> x(40);
> > > suppose we allowed: std::span<std::float64_t, 40>(x);
> > >
> > > Philosophically, I want a non-owning view of the data, so maybe
> > > std::span is a good choice?
> > > I don't want actual conversion; I think I'd prefer compilation to fail.
>
> > are we forcing that double and float64_t are both the same bit
> repreresentaiton?
>
> If the std::span object above is constructible, then yes, double and
> float64_t have the same bit representation.
> In general, double and float64_t may not have the same bit
> representation. If they do not, I'm proposing the code above not compile.
>
> > There are many who want std::float64_t to be ieee-754, even if the
> hardware is different.
>
> Yes, it is written in [basic.extended.fp] that std::float64_t is ieee-754
> binary64:
> If the implementation supports an extended floating-point type whose
> properties are specified by the ISO/IEC 60559 floating-point interchange
> format binary64, then the typedef-name std::float64_t is declared in the
> header <stdfloat> and names such a type, the macro __STDCPP_FLOAT64_T__ is
> defined, and the floating-point literal suffixes f64 and F64 are supported.
>
> > I know ieee-754 is from 1985 and nearly everyone uses it and thus double
> is for paractial purposes ieee-754, but are we forcing that
>
> No, we're not forcing that. (Takum arithmetic, for example, is
> interesting: https://www.arith2025.org/program.html)
> The standard floating-point types (float, double, long double) are not
> required to be IEEE-754.
> If however, e.g., double is IEEE-754 binary64, then I am looking for a way
> for my program that uses double to use a library written to use
> std::float64_t.
> The scalars convert nicely. The struggle is with pointers.
>
> > If floating point might be something else (either in the future, on
> maybe on esoteric hardware nobody in this discussion is aware of) then we
> need to figure out how casting works. Do we say static_cast will convert
> between the two, or make it a compiler error if the implementation doesn't
> use the same bit representatoin for both.
>
> Yes, static_cast can convert between different floating-point types. For
> example, static_cast between float and double works and changes the bits.
>
> > The second question is when the implementation knows the underlying bit
> representation is exactly the same do we allow aliasing.
>
> There is push-back on allowing aliasing (i.e., on prohibiting TBAA
> optimizations based on double and std::float64_t being different types).
> Unfortunately, I find myself agreeing. But I want to allow gradual
> adoption of std::float64_t, so I want a painless way to cast double* to
> std::float64_t* and back again.
> This casting of pointers only needs to work if double is IEEE-754 binary64.
> Maybe the magic can be hidden in a new constructor for std::span.
>
>
> > -----Original message-----
> > From: Sebastian Wittmeier <wittmeier_at_[hidden]>
> > Sent: Monday, August 25 2025, 2:05 pm
> > To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>;
> > Paul Caprioli <paul_at_[hidden]>
> > Subject: AW: [std-proposals] TBAA and extended floating-point types
> >
> > Perhaps we need bit_cast or other conversions for arrays and templated
> > containers. Either as noop or as actual conversion.
> >
> > ranges? adapter classes? Do we have enough facilities?
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Paul Caprioli <paul_at_[hidden]>
> > Gesendet: Mo 25.08.2025 22:03
> > Betreff: RE: [std-proposals] TBAA and extended floating-point types
> > An: std-proposals_at_[hidden];
> > CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
> >> What about bitcast instead?
> >
> > I'm thinking about the following, and don't see how bitcast is useful:
> >
> > void daxpy(std::size_t n, const std::float64_t alpha, const
> std::float64_t* x,
> > std::float64_t* y) {
> > for (std::size_t i = 0; i < n; ++i) y[i] += alpha * x[i];
> > }
> >
> > int main() {
> > std::size_t n = 40;
> > double alpha = 2.0;
> > std::vector<double> x(n, 1.0);
> > std::vector<double> y(n, 3.0);
> >
> > daxpy(n, alpha, x.data(), y.data());
> >
> > std::cout << y[17] << '\n'; // UB
> > }
> >
> >
> > --
> > 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
>