This is the mail archive of the 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 Thu, 2016-05-05 at 23:35 +0000, Joseph Myers wrote:
> On Thu, 5 May 2016, Paul E. Murphy wrote:
> > As Joseph pointed out earlier in [1] and [2] we can't hack and slash our
> > way into supporting this, but IMO, the consensus driven model doesn't
> > encourage a large upfront design, as interested parties only seem to
> > show up at the tail end (during patch submissions). I think we need
> > consensus on what the end result will look like, and what steps will
> > get us there.
>  and later could run for more.
> > My proposed design for source structure is:
> > * sysdeps/ieee754/f128/ holds all the __float128
> >   (e.g sysdeps/ieee754/f64x-ibm for a _Float64x type based off ibm128)
> _Float64x cannot be based on ibm128; it must have IEEE semantics.  It 
> could be an alias for __float128, or for x86 extended (I don't see any 
> circumstances in which it would be anything else).
Yes it seems that _Float64x are specifically defined to enclusively
cover x86 80-bit and seems to exclude the IBM long double.

I assume that you object to using a standard "extented" type in a none
standard way.

How about using an "extendable" type unique to IBM long double.

Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:

Is this acceptable?

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