on 2022/12/14 18:33, Jakub Jelinek wrote: > On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote: >>> The hacks with different precisions of powerpc 128-bit floating types are >>> very unfortunate, it is I assume because the middle-end asserted that scalar >>> floating point types with different modes have different precision. >>> We no longer assert that, as BFmode and HFmode (__bf16 and _Float16) have >>> the same 16-bit precision as well and e.g. C++ FE knows to treat standard >>> vs. extended floating point types vs. other unknown floating point types >>> differently in finding result type of binary operations or in which type >>> comparisons will be done. >> >> It's good news, for now those three long double modes on Power have different >> precisions, if they can have the same precision, I'd expect the ICE should be >> gone. > > I'm talking mainly about r13-3292, the asserts now check different modes > have different precision unless it is half vs. brain or vice versa, but > could be changed further, but if the precision is the same, the FEs > and the middle-end needs to know how to deal with those. > For C++23, say when __ibm128 is the same as long double and _Float128 is > supported, the 2 types are unordered (neither is a subset or superset of > the other because there are many _Float128 values one can't represent > in double double (whether anything with exponent larger than what double > can represent or most of the more precise values), but because of the > variable precision there are double double values that can't be represented > in _Float128 either) and so we can error on comparisons of those or on > arithmetics with such arguments (unless explicitly converted first). > But for backwards compatibility we can't do that for __float128 vs. __ibm128 > and so need to backwards compatibly decide what wins. And for the > middle-end say even for mode conversions decide what is widening and what is > narrowing even when they are unordered.
Thanks for the pointer! I don't have good understanding on the backwards compatibility on those conversions, guessing Mike, Segher and David would have more insights. BR, Kewen
