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: Adding __float128 (i.e TS 18661-3)


On 06/05/16 23:03, Joseph Myers wrote:
> On Fri, 6 May 2016, Paul E. Murphy wrote:
>> Likewise, should these also expose appropriate *_finite symbols too? Or,
>> is such even permissible under this standard?
> 
> __*_finite are in the implementation namespace.  So it's always fine to 
> have those aliases.  *But* the principles of ABI minimization (keeping 
> down the number of shared library exports) mean that if float128 and long 
> double functions alias each other (on existing platforms where long double 
> is binary128), those functions should not have two sets of aliases 

is it acceptable to alias functions with incompatible types?

> __*l_finite and __*f128_finite.  The design for math-finite.h needs to 
> allow for that.  (For normal public functions, if we add *f128 API support 
> when it's the same format as long double - and I think we should, just 
> like *f32 *f64 *f32x *f64x variants as applicable - then ISO C rules about 

i assume gcc does not yet support _Float32 and _Float64
and *f32 and *f64 will only be added once there is support
for them.

> when you can declare a function yourself mean that most functions 
> unavoidably do need duplicate shared library exports.)
> 


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