This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv2 3/5] ldbl-128: Rename 'long double' to '_Float128'
On 08/18/2016 04:05 PM, Joseph Myers wrote:
> On Thu, 18 Aug 2016, Paul E. Murphy wrote:
>
>> * sysdeps/ieee754/ldbl-128/math_ldbl.h:
>> [!defined (FLT128_MANT_DIG)] (_Float128): Define as long double
>> for compilers which do not support this type.
>
> No, that's not the right condition. For architectures where long double
> is binary128, with compilers that support _Float128, they are distinct
> types, and so _Float128 must be defined to long double (and constants
> likeiwse have long double type) so that functions whose type (declared in
> other headers) involves long double are also defined with the correct
> type.
>
> So: if these files are being built for long double, regardless of whether
> _Float128 is supported, _Float128 must be a macro defined to long double
> so the functions get the correct type. And if they are being built for
> _Float128, via wrappers in some other sysdeps directory, it's for files in
> that sysdeps directory to do whatever's needed to avoid the redefining of
> _Float128 as long double.
Ok, I didn't realize they'd be treated as such. I will remove the
conditional logic in the next patch pending anymore feedback.
>
> It's only in a context where the functions are defined directly with *f128
> names that you can avoid defining _Float128 to long double when the
> compiler supports _Float128 and they have the same format. (In that
> context, you instead need to avoid the headers declaring the long double
> functions that will be aliased to the _Float128 ones, to avoid errors
> about the aliases having incompatible types.)
Adding ieee754/ldbl-128 to the Implies of machine supporting _Float128
transitioning to a binary128 long double will surely be a mistake?
Anyhow, I suspect this will be the least of the problems supporting a
third long double type, nor should it be difficult to work around.