Re: [PATCH] Provide a C++ version of iseqsig

[Jonathan Wakely <jwakely at redhat dot com>]

On 03/11/17 16:31 +0000, Joseph Myers wrote:
> On Fri, 3 Nov 2017, Jonathan Wakely wrote:
>
> > The C++ standard explicitly requires all functions from the C library
> > to be defined as real functions, and *not* macros. This means the C++
> > library has to do #undef for every function from the C library that
> > might be defined as a macro. Doing that here would make iseqsig
> > unusable, so a C++ implementation that wanted to define it would need
> > to provide its own definition. If you define an inline function it
> > just works, and there's no problem. Most C++ programmers want fewer
> > macros, not more.
>
> With all these C++ inline functions in math.h for TS 18661-1 macros
> (issignaling, iszero, iseqsig; iscanonical only for configurations where
> it's nontrivial; not issubnormal, because that's defined in terms of
> fpclassify so has no problems with __MATH_TG given libstdc++ defines
> fpclassify as a function) there's a question of what the interactions with
> libstdc++ should look like in future.
>
> For the C99 type-generic macros, libstdc++, not glibc, deals with
> providing the overloaded function versions for C++ code.  TS 18661-1 is
> expected to be integrated into the C standard for C2x, which I suppose
> makes it likely to become part of standard C++ as well when the C2x
> standard library is integrated into C++.  So should libstdc++ be
> responsible for providing function versions of all these macros?  Or

I'd be happy to define them in libstdc++, as long as we have a
__builtin_sigseq in GCC that can be used for it.

So in that case, only defining it as a macro in glibc is the right
option, as libstdc++ can just #undef it. But then we should ask if
it's worth even defining it as a macro for C++.

> should glibc do it?  (If glibc should do it, that implies it should
> provide a function version of iscanonical for C++ in the case where
> iscanonical is trivial and just converts its argument to its semantic type
> and returns 0, not just in the nontrivial cases, and that it should
> provide a function version of issubnormal for C++ although the macro
> version should actually work for C++ at present even in the presence of
> __float128 support.)
>
> I have been making the assumption, in both the GCC and the glibc context,
> that any C++ bindings for IEEE 754 interchange and extended types will be
> class-based, not following the C _FloatN, _FloatNx, given that C++ chose
> class-based std::decimal bindings for decimal floating point (and for
> complex numbers), so that while __float128 should be supported for C++
> code in the case where it exists with a distinct format from long double
> (and if libstdc++ supports __float128, or a new class-based binding for
> that format, it should be able to call the glibc *f128 functions as part
> of implementing that support), the C++ case in glibc does not need to deal
> with e.g. _Float64x, _Float128, long double all existing as distinct types
> with the same format (whereas the C code does need to deal with that).
>
> > And then provide a function template to handle mixed types, which
> > converts both arguments to the promoted type:
>
> Does this achieve the desired effect of calling the function for the
> __MATH_EVAL_FMT2 type even when both arguments have the same type (but the
> __MATH_EVAL_FMT2 type is wider than that type)?

Ah, no, it doesn't. If __typeof__(1.0f + 1.0f) is double, then it
would incorrectly call __iseqsig(float, float).

Maybe it's better to leave the C++ definitions to libstdc++, where we
can use decltype and use arbitrarily complicated template
metaprogramming that probably isn't appropriate for glibc.