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
