Re: [RFC/PATCH] Remove the workaround for _Float128 precision [PR107299]

["Kewen.Lin" <linkw@linux.ibm.com>]

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