* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-21 21:40 ` Joseph Myers
@ 2022-12-21 22:45 ` Jakub Jelinek
2022-12-22 6:37 ` Kewen.Lin
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Jakub Jelinek @ 2022-12-21 22:45 UTC (permalink / raw)
To: Joseph Myers
Cc: Segher Boessenkool, Kewen.Lin, GCC Patches, Michael Meissner,
David Edelsohn, Peter Bergner, Richard Biener, Richard Sandiford
On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > continue;
> > > int precision = GET_MODE_PRECISION (mode);
> > > - /* Work around the rs6000 KFmode having precision 113 not
> > > - 128. */
> >
> > It has precision 126 now fwiw.
> >
> > Joseph: what do you think about this patch? Is the workaround it
> > removes still useful in any way, do we need to do that some other way if
> > we remove this?
>
> I think it's best for the TYPE_PRECISION, for any type with the binary128
> format, to be 128 (not 126).
Agreed.
> It's necessary that _Float128, _Float64x and long double all have the same
> TYPE_PRECISION when they have the same (binary128) format, or at least
> that TYPE_PRECISION for _Float128 >= that for long double >= that for
> _Float64x, so that the rules in c_common_type apply properly.
>
> How the TYPE_PRECISION compares to that of __ibm128, or of long double
> when that's double-double, is less important.
I guess it can affect the common type for {long double
(when binary128),_Float128,_Float64x,__float128,__ieee128} vs. {long double (when
ibm128),__ibm128}, especially in C (for C++ only when non-standard types are
involved (__float128, __ieee128, __ibm128).
But I think unless we error (e.g. in C++ when we see unordered floating
point types), prefering binary128 is better, it certainly has much bigger
exponent range over __ibm128 and most of the time also the precision
(__ibm128 wastes some bits on the other exponent).
Jakub
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-21 21:40 ` Joseph Myers
2022-12-21 22:45 ` Jakub Jelinek
@ 2022-12-22 6:37 ` Kewen.Lin
2022-12-22 18:18 ` Segher Boessenkool
` (2 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Kewen.Lin @ 2022-12-22 6:37 UTC (permalink / raw)
To: Joseph Myers
Cc: GCC Patches, Michael Meissner, David Edelsohn, Jakub Jelinek,
Peter Bergner, Richard Biener, Richard Sandiford,
Segher Boessenkool
Hi Joseph,
on 2022/12/22 05:40, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
>>> --- a/gcc/tree.cc
>>> +++ b/gcc/tree.cc
>>> @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
>>> if (!targetm.floatn_mode (n, extended).exists (&mode))
>>> continue;
>>> int precision = GET_MODE_PRECISION (mode);
>>> - /* Work around the rs6000 KFmode having precision 113 not
>>> - 128. */
>>
>> It has precision 126 now fwiw.
>>
>> Joseph: what do you think about this patch? Is the workaround it
>> removes still useful in any way, do we need to do that some other way if
>> we remove this?
>
> I think it's best for the TYPE_PRECISION, for any type with the binary128
> format, to be 128 (not 126).
I agree that it's more reasonable to use 128 for it (all of them) eventually,
but what I thought is that if we can get rid of this workaround first to make
the bootstrapping survive. Commit r9-1302-g6a8886e45f7eb6 makes TFmode/
KFmode/IFmode have different precisions with some reasons, Jakub mentioned
commit r13-3292, I think later we can refer to it and have a try to unique
those modes to have the same precisions (probably next stage1), I guess Mike
may have more insightful comments here.
>
> It's necessary that _Float128, _Float64x and long double all have the same
> TYPE_PRECISION when they have the same (binary128) format, or at least
> that TYPE_PRECISION for _Float128 >= that for long double >= that for
> _Float64x, so that the rules in c_common_type apply properly.
>
a. _Float128, _Float64x and long double all have the same
TYPE_PRECISION when they have the same (binary128) format.
b. TYPE_PRECISION for _Float128 >= that for long double
>= that for _Float64x.
**Without this patch**,
1) -mabi=ieeelongdouble (these three are ieee128)
_Float128 => 128 ("type => its TYPE_PRECISION")
_Float64x => 128
long double => 127
// Neither a and b holds.
2) -mabi=ibmlongdouble (long double is ibm128)
_Float128 => 128
_Float64x => 128
long double => 127
// a N/A, b doesn't hold.
**With this patch**,
1) -mabi=ieeelongdouble
_Float128 => 127
_Float64x => 127
long double => 127
// both a and b hold.
2) -mabi=ibmlongdouble
_Float128 => 126
_Float64x => 126
long double => 127
// a N/A, b doesn't hold.
IMHO, this patch improves the status quo slightly.
BR,
Kewen
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-21 21:40 ` Joseph Myers
2022-12-21 22:45 ` Jakub Jelinek
2022-12-22 6:37 ` Kewen.Lin
@ 2022-12-22 18:18 ` Segher Boessenkool
2022-12-22 19:48 ` Joseph Myers
2023-01-03 23:27 ` Michael Meissner
2023-01-07 0:41 ` Michael Meissner
4 siblings, 1 reply; 14+ messages in thread
From: Segher Boessenkool @ 2022-12-22 18:18 UTC (permalink / raw)
To: Joseph Myers
Cc: Kewen.Lin, GCC Patches, Michael Meissner, David Edelsohn,
Jakub Jelinek, Peter Bergner, Richard Biener, Richard Sandiford
Hi!
On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > continue;
> > > int precision = GET_MODE_PRECISION (mode);
> > > - /* Work around the rs6000 KFmode having precision 113 not
> > > - 128. */
> >
> > It has precision 126 now fwiw.
> >
> > Joseph: what do you think about this patch? Is the workaround it
> > removes still useful in any way, do we need to do that some other way if
> > we remove this?
You didn't address these questions. We don't see negative effects from
removing this workaround, but it isn't clear (to me) what problems were
there that caused you to do this workaround. Do you remember maybe? Or
can we just delete it and try to forget such worries :-)
> I think it's best for the TYPE_PRECISION, for any type with the binary128
> format, to be 128 (not 126).
Well, but why? Of course it looks nicer, and it is a gross workaround
to have different precisions for the different 128-bit FP modes, more so
if two modes are really the same, but in none of the ways floating point
precision is defined would it be 128 for any 128-bit mode.
> It's necessary that _Float128, _Float64x and long double all have the same
> TYPE_PRECISION when they have the same (binary128) format,
Yes, agreed. Or even if it would be not necessary it is the only sane
thing to do.
Segher
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-22 18:18 ` Segher Boessenkool
@ 2022-12-22 19:48 ` Joseph Myers
2022-12-22 22:09 ` Segher Boessenkool
0 siblings, 1 reply; 14+ messages in thread
From: Joseph Myers @ 2022-12-22 19:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Kewen.Lin, GCC Patches, Michael Meissner, David Edelsohn,
Jakub Jelinek, Peter Bergner, Richard Biener, Richard Sandiford
On Thu, 22 Dec 2022, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > > --- a/gcc/tree.cc
> > > > +++ b/gcc/tree.cc
> > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > > continue;
> > > > int precision = GET_MODE_PRECISION (mode);
> > > > - /* Work around the rs6000 KFmode having precision 113 not
> > > > - 128. */
> > >
> > > It has precision 126 now fwiw.
> > >
> > > Joseph: what do you think about this patch? Is the workaround it
> > > removes still useful in any way, do we need to do that some other way if
> > > we remove this?
>
> You didn't address these questions. We don't see negative effects from
> removing this workaround, but it isn't clear (to me) what problems were
> there that caused you to do this workaround. Do you remember maybe? Or
> can we just delete it and try to forget such worries :-)
The purpose was to ensure that _Float128's TYPE_PRECISION was at least as
large as that of long double, in the case where they both have binary128
format. I think at that time, in GCC 7, it was possible for _Float128 to
be KFmode and long double to be TFmode, with those being different modes
with the same format.
In my view, it would be best not to have different modes with the same
format - not simply ensure types with the same format have the same mode,
but avoid multiple modes with the same format existing in the compiler at
all. That is, TFmode should be the same mode as one of KFmode and IFmode
(one name should be defined as a macro for the other name, or something
similar). If you don't have different modes with the same format, many of
the problems go away.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-22 19:48 ` Joseph Myers
@ 2022-12-22 22:09 ` Segher Boessenkool
0 siblings, 0 replies; 14+ messages in thread
From: Segher Boessenkool @ 2022-12-22 22:09 UTC (permalink / raw)
To: Joseph Myers
Cc: Kewen.Lin, GCC Patches, Michael Meissner, David Edelsohn,
Jakub Jelinek, Peter Bergner, Richard Biener, Richard Sandiford
On Thu, Dec 22, 2022 at 07:48:28PM +0000, Joseph Myers wrote:
> On Thu, 22 Dec 2022, Segher Boessenkool wrote:
> > On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> > > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> > > > Joseph: what do you think about this patch? Is the workaround it
> > > > removes still useful in any way, do we need to do that some other way if
> > > > we remove this?
> >
> > You didn't address these questions. We don't see negative effects from
> > removing this workaround, but it isn't clear (to me) what problems were
> > there that caused you to do this workaround. Do you remember maybe? Or
> > can we just delete it and try to forget such worries :-)
>
> The purpose was to ensure that _Float128's TYPE_PRECISION was at least as
> large as that of long double, in the case where they both have binary128
> format. I think at that time, in GCC 7, it was possible for _Float128 to
> be KFmode and long double to be TFmode, with those being different modes
> with the same format.
They still are separate modes :-( It always is possible to create
KFmode entities (via mode((KF)) if nothing else) and those should behave
exactly the same as TFmode if TFmode is IEEE QP (just like KFmode always
is).
> In my view, it would be best not to have different modes with the same
> format - not simply ensure types with the same format have the same mode,
> but avoid multiple modes with the same format existing in the compiler at
> all. That is, TFmode should be the same mode as one of KFmode and IFmode
> (one name should be defined as a macro for the other name, or something
> similar).
Right, TFmode should be just a different *name* for either IFmode or
KFmode (and both of those modes always exist if either does).
> If you don't have different modes with the same format, many of
> the problems go away.
I used to have patches for this. A few problems remained, but this
was very long ago, who knows where we stand now. I'll recreate those
patches, let's see where that gets us.
Thanks for the help,
Segher
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-21 21:40 ` Joseph Myers
` (2 preceding siblings ...)
2022-12-22 18:18 ` Segher Boessenkool
@ 2023-01-03 23:27 ` Michael Meissner
2023-01-07 0:41 ` Michael Meissner
4 siblings, 0 replies; 14+ messages in thread
From: Michael Meissner @ 2023-01-03 23:27 UTC (permalink / raw)
To: Joseph Myers
Cc: Segher Boessenkool, Kewen.Lin, GCC Patches, Michael Meissner,
David Edelsohn, Jakub Jelinek, Peter Bergner, Richard Biener,
Richard Sandiford
On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > continue;
> > > int precision = GET_MODE_PRECISION (mode);
> > > - /* Work around the rs6000 KFmode having precision 113 not
> > > - 128. */
> >
> > It has precision 126 now fwiw.
> >
> > Joseph: what do you think about this patch? Is the workaround it
> > removes still useful in any way, do we need to do that some other way if
> > we remove this?
>
> I think it's best for the TYPE_PRECISION, for any type with the binary128
> format, to be 128 (not 126).
>
> It's necessary that _Float128, _Float64x and long double all have the same
> TYPE_PRECISION when they have the same (binary128) format, or at least
> that TYPE_PRECISION for _Float128 >= that for long double >= that for
> _Float64x, so that the rules in c_common_type apply properly.
>
> How the TYPE_PRECISION compares to that of __ibm128, or of long double
> when that's double-double, is less important.
When I did the original implementation years ago, there were various implicit
assumptions that for any one precision, there must be only one floating point
type.
I tend to agree that logically the precision should be 128, but until we go
through and fix all of these assumptions, it may be problematical. This shows
up in the whole infrastructure of looking for a FP type with larger precision
than a given precision. There just isn't an ordering that works and preserves
all values.
I'm coming to think that we may want 2 types of FP, one is a standard FP type
where you can convert to a larger type, and the other for various FP types
where there is no default widening conversion.
And logically there is the issue with 16-bit floats, giving we have different
versions of 16-bit float.
And if an implementation ever wanted to support both BID and DFP decimal types
at the same time, they would have similar issues.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2022-12-21 21:40 ` Joseph Myers
` (3 preceding siblings ...)
2023-01-03 23:27 ` Michael Meissner
@ 2023-01-07 0:41 ` Michael Meissner
2023-01-10 3:21 ` Michael Meissner
4 siblings, 1 reply; 14+ messages in thread
From: Michael Meissner @ 2023-01-07 0:41 UTC (permalink / raw)
To: Joseph Myers
Cc: Segher Boessenkool, Kewen.Lin, GCC Patches, Michael Meissner,
David Edelsohn, Jakub Jelinek, Peter Bergner, Richard Biener,
Richard Sandiford
On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> On Wed, 21 Dec 2022, Segher Boessenkool wrote:
>
> > > --- a/gcc/tree.cc
> > > +++ b/gcc/tree.cc
> > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > continue;
> > > int precision = GET_MODE_PRECISION (mode);
> > > - /* Work around the rs6000 KFmode having precision 113 not
> > > - 128. */
> >
> > It has precision 126 now fwiw.
> >
> > Joseph: what do you think about this patch? Is the workaround it
> > removes still useful in any way, do we need to do that some other way if
> > we remove this?
>
> I think it's best for the TYPE_PRECISION, for any type with the binary128
> format, to be 128 (not 126).
>
> It's necessary that _Float128, _Float64x and long double all have the same
> TYPE_PRECISION when they have the same (binary128) format, or at least
> that TYPE_PRECISION for _Float128 >= that for long double >= that for
> _Float64x, so that the rules in c_common_type apply properly.
>
> How the TYPE_PRECISION compares to that of __ibm128, or of long double
> when that's double-double, is less important.
I spent a few days on working on this. I have patches to make the 3 128-bit
types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro
(FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as
FRACTIONAL_FLOAT_MODE.
This will create a floating point mode that is a normal floating point mode,
but the GET_MODE_WIDER and GET_MODE_2XWIDER macros will never return it. By
declaring both IFmode and KFmode to not be widened to, but noral TFmode is, it
eliminates the problems where an IBM expression got converted to IEEE, which
can mostly (but not always) contain the value. In addition, on power8, it
means it won't call the KF mode emulator functions, just the IF functions.
We need to have one 128-bit mode (TFmode) that is not declared as NO_WARN, or
long double won't be created, since float_mode_for_size (128) will not be able
to find the correct type.
I did have to patch convert_mode_scalar so that it would not abort if it was
doing a conversion between two floating point types with the same precision.
I tested this with the first patch from the previous set of patches (that
rewrites complex multiply/divide built-in setup). I think that patch is useful
as a stand alone patch.
I also used Kewen Lin's patch from December 27th in build_common_tree_nodes to
do the test. I haven't tested if this particular patch fixes this problem, or
it fixes something else.
Finally, I used the third patch in my series of patches that straightens out
128<->128 FP conversions. That patch needed to be tweaked slightly, as one of
the conversations became FLOAT_EXTEND instead of FLOAT_TRUNCATE.
We don't have a RTL operation that says convert from one floating point type to
another where both types are the same size. Whether FLOAT_EXTEND is used or
FLOAT_TRUNCATE, used to depend on whether the TYPE_PRECISION was greater or
lesser. Now that they are the same, it arbitrarily picks FLOAT_EXTEND.
While I still think the 2nd patch is important, it isn't needed with the above
patches.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2023-01-07 0:41 ` Michael Meissner
@ 2023-01-10 3:21 ` Michael Meissner
2023-01-10 18:23 ` Jakub Jelinek
0 siblings, 1 reply; 14+ messages in thread
From: Michael Meissner @ 2023-01-10 3:21 UTC (permalink / raw)
To: Michael Meissner, Joseph Myers, Segher Boessenkool, Kewen.Lin,
GCC Patches, David Edelsohn, Jakub Jelinek, Peter Bergner,
Richard Biener, Richard Sandiford
On Fri, Jan 06, 2023 at 07:41:07PM -0500, Michael Meissner wrote:
> On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote:
> > On Wed, 21 Dec 2022, Segher Boessenkool wrote:
> >
> > > > --- a/gcc/tree.cc
> > > > +++ b/gcc/tree.cc
> > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char)
> > > > if (!targetm.floatn_mode (n, extended).exists (&mode))
> > > > continue;
> > > > int precision = GET_MODE_PRECISION (mode);
> > > > - /* Work around the rs6000 KFmode having precision 113 not
> > > > - 128. */
> > >
> > > It has precision 126 now fwiw.
> > >
> > > Joseph: what do you think about this patch? Is the workaround it
> > > removes still useful in any way, do we need to do that some other way if
> > > we remove this?
> >
> > I think it's best for the TYPE_PRECISION, for any type with the binary128
> > format, to be 128 (not 126).
> >
> > It's necessary that _Float128, _Float64x and long double all have the same
> > TYPE_PRECISION when they have the same (binary128) format, or at least
> > that TYPE_PRECISION for _Float128 >= that for long double >= that for
> > _Float64x, so that the rules in c_common_type apply properly.
> >
> > How the TYPE_PRECISION compares to that of __ibm128, or of long double
> > when that's double-double, is less important.
>
> I spent a few days on working on this. I have patches to make the 3 128-bit
> types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro
> (FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as
> FRACTIONAL_FLOAT_MODE.
...
I had the patches to change the precision to 128, and I just ran them. C and
C++ do not seem to be bothered by changing the precision to 128 (once I got it
to build, etc.). But Fortran on the other hand does actually use the precision
to differentiate between IBM extended double and IEEE 128-bit. In particular,
the following 3 tests fail when long double is IBM extended double:
gfortran.dg/PR100914.f90
gfortran.dg/c-interop/typecodes-array-float128.f90
gfortran.dg/c-interop/typecodes-scalar-float128.f90
I tried adding code to use the old precisions for Fortran, but not for C/C++,
but it didn't seem to work.
So while it might be possible to use a single 128 for the precision, it needs
more work and attention, particularly on the Fortran side.
I'm not sure it is worth it to try and change things.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2023-01-10 3:21 ` Michael Meissner
@ 2023-01-10 18:23 ` Jakub Jelinek
2023-01-11 20:26 ` Michael Meissner
0 siblings, 1 reply; 14+ messages in thread
From: Jakub Jelinek @ 2023-01-10 18:23 UTC (permalink / raw)
To: Michael Meissner, Joseph Myers, Segher Boessenkool, Kewen.Lin,
GCC Patches, David Edelsohn, Peter Bergner, Richard Biener,
Richard Sandiford
On Mon, Jan 09, 2023 at 10:21:52PM -0500, Michael Meissner wrote:
> I had the patches to change the precision to 128, and I just ran them. C and
> C++ do not seem to be bothered by changing the precision to 128 (once I got it
> to build, etc.). But Fortran on the other hand does actually use the precision
> to differentiate between IBM extended double and IEEE 128-bit. In particular,
> the following 3 tests fail when long double is IBM extended double:
>
> gfortran.dg/PR100914.f90
> gfortran.dg/c-interop/typecodes-array-float128.f90
> gfortran.dg/c-interop/typecodes-scalar-float128.f90
>
> I tried adding code to use the old precisions for Fortran, but not for C/C++,
> but it didn't seem to work.
>
> So while it might be possible to use a single 128 for the precision, it needs
> more work and attention, particularly on the Fortran side.
Can't be more than a few lines changed in the fortran FE.
Yes, the FE needs to know if it is IBM extended double or IEEE 128-bit so
that it can decide on the mangling - where to use the artificial kind 17 and
where to use 16. But as long as it can figure that out, it doesn't need to
rely on a particular precision.
Jakub
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]
2023-01-10 18:23 ` Jakub Jelinek
@ 2023-01-11 20:26 ` Michael Meissner
0 siblings, 0 replies; 14+ messages in thread
From: Michael Meissner @ 2023-01-11 20:26 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Michael Meissner, Joseph Myers, Segher Boessenkool, Kewen.Lin,
GCC Patches, David Edelsohn, Peter Bergner, Richard Biener,
Richard Sandiford
On Tue, Jan 10, 2023 at 07:23:23PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 09, 2023 at 10:21:52PM -0500, Michael Meissner wrote:
> > I had the patches to change the precision to 128, and I just ran them. C and
> > C++ do not seem to be bothered by changing the precision to 128 (once I got it
> > to build, etc.). But Fortran on the other hand does actually use the precision
> > to differentiate between IBM extended double and IEEE 128-bit. In particular,
> > the following 3 tests fail when long double is IBM extended double:
> >
> > gfortran.dg/PR100914.f90
> > gfortran.dg/c-interop/typecodes-array-float128.f90
> > gfortran.dg/c-interop/typecodes-scalar-float128.f90
> >
> > I tried adding code to use the old precisions for Fortran, but not for C/C++,
> > but it didn't seem to work.
> >
> > So while it might be possible to use a single 128 for the precision, it needs
> > more work and attention, particularly on the Fortran side.
>
> Can't be more than a few lines changed in the fortran FE.
> Yes, the FE needs to know if it is IBM extended double or IEEE 128-bit so
> that it can decide on the mangling - where to use the artificial kind 17 and
> where to use 16. But as long as it can figure that out, it doesn't need to
> rely on a particular precision.
I agree that in theory it should be simple to fix. Unfortunately the patches
that I was working on cause some other failures that I need to investigate.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com
^ permalink raw reply [flat|nested] 14+ messages in thread