On Wed, Feb 22, 2023 at 06:37:39PM +0800, Kewen.Lin wrote:
> Thanks for working on this! If updating libgcc source to workaround this
> issue
> is the best option we can have at this moment, it's fine.
Thanks. Yes, I agree that it does not fix the root issue.
> Comparing to one
> previous proposal which removes the workaround in build_common_tree_nodes for
> rs6000 KFmode, a bit concern on this one is that users can still meet the ICE
> with a simple case like:
>
> typedef float TFtype __attribute__((mode (TF)));
>
> TFtype
> test (TFtype t)
> {
> return __builtin_copysignf128 (1.0q, t);
> }
>
> but I guess they would write this kind of code very rarely?
I tend to think that it is better to consistantly use __float128/_Float128
types with the 'f128' functions, and use long double with the 'l'. It would be
nice to fix the root cause (of __float128 and _Float128 not being the same type
within the compiler).
It is complicated by the fact that until C++2x, you can't use the _Float128
type. You can use the __float128 and __ibm128 extensions, but you can't use
those extensions with _Complex. This means for C++, you have to use the
__attrbibute__((mode)) to get to the complex type. And due to the way I
initially implemented it, whether you use T{C,F}, K{C,F}, and I{C,F} depends on
the switches.
But without fixing that (which is fairly complex), I really want the master
branch fixed so you can build GCC with long double defaulting to IEEE 128-bit.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
