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: meiss...@linux.ibm.com
