This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]