On Mon, 17 Oct 2022 at 17:26, Jakub Jelinek <ja...@redhat.com> wrote:
>
> Hi!
>
> On Mon, Oct 17, 2022 at 02:07:00PM +0100, Jonathan Wakely wrote:
> > Yes, that's now https://cplusplus.github.io/LWG/issue3790
> > The current proposed resolution is to just restore the C++20 functions
> > and not provide anything for the new types.
>
> Ok.
>
> > > If you want to have <cmath> done in a different way, e.g. the patch
> > > groups a lot of different function overloads by the floating point type,
> > > is that ok or do you want to have them one function at a time for all
> > > types,
> > > then next?
> >
> > No, I think this way makes more sense. Otherwise the line count in the
> > file will baloon with all the repeated #if #endif directives.
>
> Ok, changed.
> I've also changed this in limits and std_abs.h (ditto for
> _GLIBCXX_USE_CONSTEXPR, _GLIBCXX_USE_NOEXCEPT).
>
> There is one thing I'm not sure about but can be handled incrementally.
> What exactly is is_iec559 supposed to be?
Nobody really knows. numeric_limits is not well specified.
> Currently for float/double/long double/__float128 it seems to be defined
> to true if the type has Inf, qNaN and denormals.
> For std::float{16,32,64,128}_t even a note in the spec says they are
> true.
> Shall it be true only if the type is actually a IEEE754 type
> (binary16/32/64/128) and false otherwise, or that + the x86 extended type?
I think it makes sense to include _Float64x there too.
> Or if it is IEEE754-like and shall it be true also for
> std::bfloat16_t?
It does have NaNs and Infs, so I suppose if double double sets it to
true, then bfloat16_t could as well. I'm unsure what the right choice
is here though.
> Yet another case is the IBM double double, which has infinities, NaNs
> and denormals, but for that one it is hard to claim it is even IEEE754-like
> (variable precision).
Yeah, I think that has is_iec559 == true which is odd.
>
> > > I could try to handle <complex> too, but am kind of lost there.
> > > The paper dropped the explicit std::complex specializations, can they stay
> > > around as is and should new overloads be added for the
> > > _Float*/__gnu_cxx::__bfloat16_t types?
> >
> > The explicit specializations can stay, they do no harm.
>
> Ok. Shall those specialization also get the P1467 changes for the ctors?
> Shall we also have specializations for the extended floating point types,
> or only conditionally (say when float is binary have _Complex _Float32
> so that we get better code)?
Oh I forgot the primary template doesn't use __complex__ for its data members.
Maybe we want to leave the primary template alone (even though it's
kinda useless for non-FP types) and add a new partial specialization
using concepts to constrain it for FP types:
template<typename _Tp> requires floating_point<_Tp>
class complex;
That would be used for all the new FP types, and we can use
__complex__ in there.
The existing explicit specializations for float/double/longdouble
would be preferred to this new partial specialization. We could
disable them for C++23, or leave them. We can decide that later
anyway.
>
> > I can take care of the <complex> changes.
>
> Ok.
>
> > > And I/O etc. support is missing, not sure I'm able to handle that and if
> > > it
> > > is e.g. possible to keep that support out of libstdc++.so.6, because what
> > > extended floating point types one has on a particular arch could change
> > > over
> > > time (I mean e.g. bfloat16_t support or float16_t support can be added
> > > etc.).
> >
> > Yes, I think we can add the I/O functions as always_inline because all
> > they're going to do is convert the argument to float, double, or long
> > double and then call the existing overloads. There will be no new
> > virtual functions.
> >
> > I can take care of that too.
>
> Thanks.
>
> Here is an updated patch that I'll test overnight (but can't commit
> until the builtins patch is reviewed as it depends on that;
> well, I could comment out the std::float128_t cmath support if
> long double is not IEEE quad and commit that only once the builtins
> patch is in).
Yes, please comment out the define in os_defines.h for now and push - thanks!
