On Fri, Aug 13, 2021 at 05:22:47PM +, Joseph Myers wrote:
> On Fri, 13 Aug 2021, Andreas Schwab wrote:
>
> > On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
> > How can it happen that __LONG_DOUBLE_IEEE128__ is not defined? This
> > file is always compiled with -mfloat128 and this l
Hi!
On Fri, Aug 13, 2021 at 05:12:47PM +, Joseph Myers wrote:
> That should be the function __divtc3. (A single libgcc binary supports
> multiple long double formats, so libgcc function names referring to
> floating-point modes need to be understood as actually referring to a
> particular
On Thu, Aug 26, 2021 at 10:51:51AM -0500, Patrick McGehearty wrote:
> I'm concerned that the old environment on gcc135.fsffrance.org
> is not showing me a typical build environment for IBM linux users
> with more modern environments.
It runs CentOS 7. This is still supported. It is getting long
On Thu, 26 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> The only complex divide routines in $HOME/usr/lib64/libgcc_s.so.1 are:
> __divdc3, __divsc3, __divtc3
Because no symbol versions are assigned to the KFmode symbols in the .ver
files, so they are only exported from libgcc.a.
I thin
Apologies in advance for the length of this reply.
Details seemed necessary to be sure we are on the same page
of understanding.
Aug 26, 2021 by Patrick McGehearty
The only IBM machines I have current access to are in the gcc fsf farm.
All studies were done on gcc135.fsffrance.org
Linux gcc135.
On Fri, 13 Aug 2021, Andreas Schwab wrote:
> On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
>
> > diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> > index a1d29d2..2b229c8 100644
> > --- a/libgcc/config/rs6000/_divkc3.c
> > +++ b/libgcc/config/rs6000/_divk
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> If _divkc3.c is not intended to provide a version of complex divide
> that handles IBM-128 format, then where should that option be handled?
That should be the function __divtc3. (A single libgcc binary supports
multiple long doub
On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
> diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> index a1d29d2..2b229c8 100644
> --- a/libgcc/config/rs6000/_divkc3.c
> +++ b/libgcc/config/rs6000/_divkc3.c
> @@ -38,10 +38,10 @@ see the files COPYING3 and CO
I see I have more to learn about gcc's interactions with IEEE-128 format
vs IBM-128 format.
As we discovered here, using the IBM-128 version of LDBL_EPSILON will
not yield correct answers as currently coded.
If _divkc3.c is not intended to provide a version of complex divide
that handles IBM-128
On Thu, Aug 12, 2021 at 04:03:13PM +, Patrick McGehearty wrote:
> This patch resolves the failure of powerpc64 long double complex divide
> in native ibm long double format after the patch "Practical improvement
> to libgcc complex divide".
[ etc. ]
Nothing in here says what has changed in v3
On Thu, Aug 12, 2021 at 04:47:42PM +, Joseph Myers wrote:
> On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> > My understanding of ibm FP mode build procedure is minimal,
> > but it seems that the _divkc3.c routine is built for both IEEE128
> > and IBM128 modes.
>
> If built fo
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> > This file includes quad-float128.h, which does some remapping from TF to
> > KF depending on __LONG_DOUBLE_IEEE128__.
> >
> > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__
> > conditional here. If __LONG_DOUB
The key code in _divkc3.c is:
#ifndef __LONG_DOUBLE_IEEE128__
#define RBIG (__LIBGCC_DF_MAX__ / 2)
#define RMIN (__LIBGCC_DF_MIN__)
#define RMIN2 (__LIBGCC_DF_EPSILON__)
#define RMINSCAL (1 / __LIBGCC_DF_EPSILON__)
#define RMAX2 (RBIG * RMIN2)
#else
#define RBIG (__LIBGCC_TF_MAX__ / 2)
#d
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> This patch resolves the failure of powerpc64 long double complex divide
> in native ibm long double format after the patch "Practical improvement
> to libgcc complex divide".
This description is not consistent with the patch.
__div
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
The new code uses the following macros which are intended to be mapped
to appropriate values according to the underlying hardwa
15 matches
Mail list logo
