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

[Joseph Myers <joseph at codesourcery dot com>]

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 
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)?

-- 
Joseph S. Myers
joseph@codesourcery.com