[PATCH] Provide a C++ version of iseqsig

[Jonathan Wakely]

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.