From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1D59F3858C5E; Tue, 20 Jun 2023 21:20:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1D59F3858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687296044; bh=fFc9rwK+eIYYgDfAqDqDYmsCX5aQESubCNPJfjYNoic=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Et5vL5Pqv1exXtAjpViFtMPL78CHEGugJvI1jd9lZUnrgWL+bPhTJH1aKKBzi7+ND RMJkmGiW7V+oupuiZfxIrXMDtUy6JrPkhHH5DPlXUNiV+/dSOpkNVpe1g1mjo4wSS5 /UyYMg+uDsYEhTpLCkg8JTiJqIm1W/ox9GRS8jl0= 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: Tue, 20 Jun 2023 21:20:43 +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: cc everconfirmed bug_status cf_reconfirmed_on 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 Peter Bergner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |linkw at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed| |2023-06-20 --- Comment #4 from Peter Bergner --- (In reply to Michael Meissner from comment #0) > I now build GCC with all 3 long double variants (IEEE 128-bit, IBM 128-bi= t, > and 64-bit). The following C test fail when when you configure the compi= ler > to use 64-bit long doubles: >=20 > gcc.dg/float128-align.c > gcc.dg/float64x-align.c > gcc.dg/tree-ssa/builtin-sprintf.c > gcc.target/powerpc/convert-fp-64.c > gcc.target/powerpc/float128-hw.c > gcc.target/powerpc/float128-hw4.c > gcc.target/powerpc/gnuattr2.c > gcc.target/powerpc/gnuattr3.c > gcc.target/powerpc/pr60203.c > gcc.target/powerpc/pr79004.c > gcc.target/powerpc/pr82748-1.c > gcc.target/powerpc/pr85657-3.c > gcc.target/powerpc/signbit-1.c Currently, the following don't FAIL anymore or are correctly disabled from running (a little of each reason): gcc.dg/tree-ssa/builtin-sprintf.c gcc.target/powerpc/convert-fp-64.c gcc.target/powerpc/float128-hw.c gcc.target/powerpc/gnuattr2.c gcc.target/powerpc/gnuattr3.c gcc.target/powerpc/pr60203.c gcc.target/powerpc/pr79004.c gcc.target/powerpc/pr82748-1.c The rest still FAIL: gcc.dg/float128-align.c gcc.dg/float64x-align.c floatn-align.h:17:1: error: static assertion failed: "max_align_t must be at least as aligned as _Float* types" 17 | _Static_assert (_Alignof (max_align_t) >=3D _Alignof (TYPE), These die because the struct we're using to check the alignment of uses long double as the "big" aligned type. We could either disable the tests using a "dg-require-effective-target longdouble128" or we could use a different more aligned type in the struct. Maybe _Float128 or _Decimal128 or use an attri= bute aligned? Thoughts? gcc.target/powerpc/float128-hw4.c float128-hw4.i: In function =E2=80=98get_float128_exponent=E2=80=99: float128-hw4.i:10:3: error: invalid parameter combination for AltiVec intri= nsic =E2=80=98__builtin_vec_scalar_extract_exp=E2=80=99 10 | return __builtin_vec_scalar_extract_exp (a); | ^~~~~~ float128-hw4.i: In function =E2=80=98get_float128_mantissa=E2=80=99: float128-hw4.i:22:3: error: invalid parameter combination for AltiVec intri= nsic =E2=80=98__builtin_vec_scalar_extract_sig=E2=80=99 22 | return __builtin_vec_scalar_extract_sig (a); | ^~~~~~ float128-hw4.i: In function =E2=80=98set_float128_exponent_float128=E2=80= =99: float128-hw4.i:46:3: error: invalid parameter combination for AltiVec intri= nsic =E2=80=98__builtin_vec_scalar_insert_exp=E2=80=99 46 | return __builtin_vec_scalar_insert_exp (a, e); The problem here seems to be we define overloaded double and _Float128 vers= ions of these builtins, but not a long double version. With -mlong-double-128, = we seem to automatically emit a cast of 'a' to 'double' and everything is fine= .=20 However, when using -mlong-double-64, no implicit cast occurs and then we r= un afoul of not having a long double version of the builtin. I can explicitly= add a cast to double and then everything is fine. Maybe the builtin harness can just "accept" long double as double when using -mlong-double-64? gcc.target/powerpc/pr85657-3.c gcc.target/powerpc/signbit-1.c pr85657-3.c:38:20: error: unknown type name =E2=80=98__ibm128=E2=80=99; did= you mean =E2=80=98__int128=E2=80=99? These die because we don't create the type __ibm128 when using -mlong-double-64, which seems strange since we do create the __float128 type used in the test cases. Mike, I assume the __ibm128 type should always be created?=