https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #6)
> I'm going to test the following to see whether anything bad falls out:
>
> --- a/gcc/config/rs6000/rs6000-builtin.cc
> +++ b/gcc/config/rs6000/rs6000-builtin.cc
> @@ -710,9 +710,9 @@ rs6000_init_builtins (void)
> For IEEE 128-bit floating point, always create the type __ieee128. If
> the
> user used -mfloat128, rs6000-c.cc will create a define from __float128
> to
> __ieee128. */
> - if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
> + if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)
> {
> - if (!TARGET_IEEEQUAD)
> + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> ibm128_float_type_node = long_double_type_node;
> else
> {
So this passes (powerpc64le-linux) bootstrap and regtesting with no regressions
using a --with-long-double-128 build. Using a --without-long-double-128 build
(ie, long double == double), signbit-1.c now ICEs with:
signbit-1.c: In function ‘do_signbit_if’:
signbit-1.c:8:64: error: unrecognizable insn:
8 | int do_signbit_if (__ibm128 a) { return __builtin_signbit (a); }
| ^
(insn 6 3 7 2 (set (reg:DF 120)
(float_truncate:DF (reg/v:IF 119 [ a ]))) "signbit-1.c":8:41 -1
(nil))
during RTL pass: vregs
signbit-1.c:8:64: internal compiler error: in extract_insn, at recog.cc:2791
...so it seems we do have some inherent assumptions baked into the backend. :-(
There are a few other testsuite regressions due to a linker warning the
testsuite wouldn't ignore:
/opt/binutils-power10/bin/ld: /tmp/ccysrhL7.o uses 64-bit long double,
/lib64/libc.so.6 uses 128-bit long double
