To answer some of my own questions about how this works (or doesn't work):
There are two different types in libgcc called TFtype, one in
quad-float128.h and one in libgcc2.h. The one in quad-float128.h is
mapped to KFmode in the case where TFmode is IBM long double, so functions
such as __mulk
On Mon, Jan 08, 2018 at 10:17:06AM -0600, Segher Boessenkool wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC serve
On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> This patch is the beginning step to switching the PowerPC long double support
> from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> It
> will be necessary to have this patch or a similar patch to allow t
On Fri, 5 Jan 2018, Michael Meissner wrote:
> On Fri, Jan 05, 2018 at 05:28:03PM +, Joseph Myers wrote:
> > On Thu, 4 Jan 2018, Michael Meissner wrote:
> >
> > > (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > > accomidate -mabi=ieeelongdouble multilibs.
> >
> > Why is
On Fri, Jan 05, 2018 at 08:22:57PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 05, 2018 at 02:07:51PM -0500, Michael Meissner wrote:
> > Yes, in C code _Float128 _Comples works. The trouble is compiling
> > libstdc++-v3. In C++, we don't have _Float128, and __float128 _Complex does
> > not work for
On Fri, Jan 05, 2018 at 02:07:51PM -0500, Michael Meissner wrote:
> Yes, in C code _Float128 _Comples works. The trouble is compiling
> libstdc++-v3. In C++, we don't have _Float128, and __float128 _Complex does
> not work for either x86 or PowerPC. So on PowerPC the code from bits/floatn.h
> is
On Fri, Jan 05, 2018 at 05:47:39PM +, Joseph Myers wrote:
> On Fri, 5 Jan 2018, Jakub Jelinek wrote:
>
> > On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > > This patch is the beginning step to switching the PowerPC long double
> > > support
> > > from IBM extended double
On Fri, Jan 05, 2018 at 06:33:50PM +0100, Jakub Jelinek wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
On Fri, Jan 05, 2018 at 05:28:03PM +, Joseph Myers wrote:
> On Thu, 4 Jan 2018, Michael Meissner wrote:
>
> > (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > accomidate -mabi=ieeelongdouble multilibs.
>
> Why is that correct in the -mabi=ibmlongdouble case?
The Powe
On Fri, 5 Jan 2018, Jakub Jelinek wrote:
> On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> > This patch is the beginning step to switching the PowerPC long double
> > support
> > from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> > It
> > will be n
On Thu, Jan 04, 2018 at 06:05:55PM -0500, Michael Meissner wrote:
> This patch is the beginning step to switching the PowerPC long double support
> from IBM extended double to IEEE 128-bit floating point on PowerPC servers.
> It
> will be necessary to have this patch or a similar patch to allow t
On Thu, 4 Jan 2018, Michael Meissner wrote:
> (CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> accomidate -mabi=ieeelongdouble multilibs.
Why is that correct in the -mabi=ibmlongdouble case?
As I understand it, TFtype is always of mode TFmode (it would certainly be
co
This patch is the beginning step to switching the PowerPC long double support
from IBM extended double to IEEE 128-bit floating point on PowerPC servers. It
will be necessary to have this patch or a similar patch to allow the GLIBC team
to begin their modifications in GLIBC 2.28, so that by the ti
13 matches
Mail list logo
