From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 06AB43858D35; Wed, 21 Jun 2023 20:31:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06AB43858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687379493; bh=etsHqEy8c7muWHBwamA+bjEhui/vtzElxZgzu0NenQo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VNkGEhEeyE9mwZ89TrmhVS2iApoXLjcD58e/RETly00o5sxN1IFTNliKFMj3NDLQT kVSBrvZOavOPhyMjqu0OF2uW+AENoo4xsHY+8hEqNfWnycP6hcOgXEfR1wHf4OLgMw q3QTZ77sFj7WTiMJFWjcAtKzZtRmbfzGnf8C6d/A= From: "bergner at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64 Date: Wed, 21 Jun 2023 20:31:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: bergner at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101002 --- Comment #7 from Peter Bergner --- (In reply to Peter Bergner from comment #6) > I'm going to test the following to see whether anything bad falls out: >=20 > --- 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 __float= 128 > to > __ieee128. */ > - if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYP= E)) > + if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE) > { > - if (!TARGET_IEEEQUAD) > + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD) > ibm128_float_type_node =3D long_double_type_node; > else > { So this passes (powerpc64le-linux) bootstrap and regtesting with no regress= ions using a --with-long-double-128 build. Using a --without-long-double-128 bu= ild (ie, long double =3D=3D double), signbit-1.c now ICEs with: signbit-1.c: In function =E2=80=98do_signbit_if=E2=80=99: 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=