Re: [PATCH] powerpc: Fix the compiler mode used with C++ when -mabi=ieeelongdouble

[Tulio Magno Quites Machado Filho <tuliom at linux dot ibm dot com>]

Joseph Myers <joseph@codesourcery.com> writes:

> On Mon, 30 Apr 2018, Tulio Magno Quites Machado Filho wrote:
>
>> I haven't seen requirement for additional macros yet, but when _Float128 is
>> typedef'ed to long double, the following changes are also necessary:
>> 
>> diff --git a/math/math.h b/math/math.h
>> index 9b6cdce431..1f1ae6014f 100644
>> --- a/math/math.h
>> +++ b/math/math.h
>> @@ -1025,7 +1025,11 @@ issignaling (long double __val)
>>    return __issignalingl (__val);
>>  #  endif
>>  }
>> -#  if __HAVE_DISTINCT_FLOAT128
>> +#  if __HAVE_DISTINCT_FLOAT128 \
>> +      && (!defined __cplusplus \
>> +	  || defined __cplusplus && __LDBL_MANT_DIG__ != 113)
>> +/* When using an IEEE 128-bit long double, _Float128 is defined as long double
>> +   in C++.  */
>>  inline int issignaling (_Float128 __val) { return __issignalingf128 (__val); }
>>  #  endif
>>  } /* extern C++ */
>> 
>> Is it architecturally-agnostic OK?
>
> I think that suggests the need for a new macro.
>
> __HAVE_DISTINCT_FLOAT128 means that _Float128 has a different format from 
> the *default* long double in this glibc - so that it's necessary to call 
> __issignalingf128 rather than __issignalingl for a _Float128 argument, for 
> example (if the format is the same as the default long double, 
> __issignalingf128 doesn't exist, on the principle of having such 
> implementation-namespace functions only exported once per floating-point 
> format, not once per floating-point type).

OK.

> In this C++ case (and this whole piece of code is only for C++, so 
> __cplusplus conditionals certainly aren't needed within there),

Aaargh!

> what you've found is that you want a conditional for whether _Float128 is 
> different from long double for the present compilation - not from the 
> default long double.
>
> So that indicates having a new macro meaning that _Float128 exists and is 
> different in format from long double for the present compilation, which 
> could be defined in bits/floatn-common.h (based on 
> __HAVE_DISTINCT_FLOAT128 and __LDBL_MANT_DIG__) rather than needing 
> duplicating in different bits/floatn.h files.

Agreed.
We need a good name and explanation to avoid the confusion with
__HAVE_DISTINCT_FLOAT*.

What about this?

/* Defined to 1 if the corresponding _FloatN type is not binary compatible
   with the corresponding ISO C type.  */
#define __HAVE_FLOAT128_UNLIKE_LDBL __HAVE_DISTINCT_FLOAT128 \
				    && __LDBL_MANT_DIG__ != 113

> Then, this would need using for issignaling and iszero and iseqsig in 
> math.h.  Those C++ definitions would *also* need changes to the inlines 
> for long double, because those inlines call either the unsuffixed or 
> l-suffixed functions depending on __NO_LONG_DOUBLE_MATH, but would need to 
> be able to call the f128-suffixed functions in the new case where long 
> double uses such functions.  So maybe some new macro would be needed to 
> indicate that case (and would then no doubt be used in other cases such as 
> to control which functions are used by bits/math-finite.h for long 
> double).

Ack.

> Something would also need doing for iscanonical, where 
> sysdeps/ieee754/ldbl-128ibm/bits/iscanonical.h would need to know that in 
> the case where long double is binary128, the same trivial definition used 
> for __NO_LONG_DOUBLE_MATH suffices (presuming you don't try to support 
> __ibm128 arguments to these macros in the case where long double is 
> binary128).

OK.

> The definitions of __MATH_TG using _Generic may also need updating to 
> handle this case, since the uses in math.h are to select such 
> once-per-format functions and thus long double selecting l-suffixed 
> functions is inappropriate for -mabi=ieeelongdouble.  (The definitions 
> using __builtin_types_compatible_p should only be applicate with old 
> compilers with insufficient -mabi=ieeelongdouble support, so you probably 
> don't need to change those.)  Note however that __MATH_TG is used in 
> math_private.h in a way for which the types used in the current 
> compilation are the relevant ones - so if any bits of glibc using 
> math_private.h get built with -mabi=ieeelongdouble, you have an issue with 
> different __MATH_TG definitions being appropriate for the different uses.

Ack.

-- 
Tulio Magno