public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64
@ 2021-06-09 20:18 meissner at gcc dot gnu.org
2021-06-10 15:17 ` [Bug testsuite/101002] " bergner at gcc dot gnu.org
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: meissner at gcc dot gnu.org @ 2021-06-09 20:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
Bug ID: 101002
Summary: Some powerpc tests fail with -mlong-double-64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I now build GCC with all 3 long double variants (IEEE 128-bit, IBM 128-bit, and
64-bit). The following C test fail when when you configure the compiler to use
64-bit long doubles:
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
@ 2021-06-10 15:17 ` bergner at gcc dot gnu.org
2021-06-11 20:54 ` segher at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-06-10 15:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
Are these tests valid for long double == double? Ie, do we just need to
disable them when using -mlong-double-64 or are these real bugs? I'm guessing
the latter for most of these tests, but just checking.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
2021-06-10 15:17 ` [Bug testsuite/101002] " bergner at gcc dot gnu.org
@ 2021-06-11 20:54 ` segher at gcc dot gnu.org
2021-06-11 20:55 ` segher at gcc dot gnu.org
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2021-06-11 20:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
The first test is for _Float128. What goes wrong there?
For all these tests yo
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
2021-06-10 15:17 ` [Bug testsuite/101002] " bergner at gcc dot gnu.org
2021-06-11 20:54 ` segher at gcc dot gnu.org
@ 2021-06-11 20:55 ` segher at gcc dot gnu.org
2023-06-20 21:20 ` bergner at gcc dot gnu.org
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2021-06-11 20:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #2)
> The first test is for _Float128. What goes wrong there?
>
> For all these tests yo
..u have to figure out what is going wrong. After that it will
likely be simple for each of them :-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (2 preceding siblings ...)
2021-06-11 20:55 ` segher at gcc dot gnu.org
@ 2023-06-20 21:20 ` bergner at gcc dot gnu.org
2023-06-21 17:30 ` bergner at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-06-20 21:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
Peter Bergner <bergner at gcc dot gnu.org> 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 <bergner at gcc dot gnu.org> ---
(In reply to Michael Meissner from comment #0)
> I now build GCC with all 3 long double variants (IEEE 128-bit, IBM 128-bit,
> and 64-bit). The following C test fail when when you configure the compiler
> to use 64-bit long doubles:
>
> 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) >= _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 attribute
aligned? Thoughts?
gcc.target/powerpc/float128-hw4.c
float128-hw4.i: In function ‘get_float128_exponent’:
float128-hw4.i:10:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_scalar_extract_exp’
10 | return __builtin_vec_scalar_extract_exp (a);
| ^~~~~~
float128-hw4.i: In function ‘get_float128_mantissa’:
float128-hw4.i:22:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_scalar_extract_sig’
22 | return __builtin_vec_scalar_extract_sig (a);
| ^~~~~~
float128-hw4.i: In function ‘set_float128_exponent_float128’:
float128-hw4.i:46:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_scalar_insert_exp’
46 | return __builtin_vec_scalar_insert_exp (a, e);
The problem here seems to be we define overloaded double and _Float128 versions
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.
However, when using -mlong-double-64, no implicit cast occurs and then we run
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 ‘__ibm128’; did you mean
‘__int128’?
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (3 preceding siblings ...)
2023-06-20 21:20 ` bergner at gcc dot gnu.org
@ 2023-06-21 17:30 ` bergner at gcc dot gnu.org
2023-06-21 17:41 ` bergner at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-06-21 17:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #5 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
> gcc.target/powerpc/pr85657-3.c
> gcc.target/powerpc/signbit-1.c
> pr85657-3.c:38:20: error: unknown type name ‘__ibm128’; did you mean
> ‘__int128’?
>
> 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?
The creation of the __ibm128 type is guarded by:
if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
Since the __ibm128 type is independent of what long double defaults to, I
assume the fix is to just remove the TARGET_LONG_DOUBLE_128 test giving us:
if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)
Or are there some (bad) inherent assumptions in the backend that IBM double
double support needing a 128-bit long double?
The creation of the __ieee128 type is only guarded by:
if (TARGET_FLOAT128_TYPE)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (4 preceding siblings ...)
2023-06-21 17:30 ` bergner at gcc dot gnu.org
@ 2023-06-21 17:41 ` bergner at gcc dot gnu.org
2023-06-21 20:31 ` bergner at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-06-21 17:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #5)
> The creation of the __ibm128 type is guarded by:
>
> if (TARGET_LONG_DOUBLE_128 && (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE))
>
> Since the __ibm128 type is independent of what long double defaults to, I
> assume the fix is to just remove the TARGET_LONG_DOUBLE_128 test giving us:
>
> if (!TARGET_IEEEQUAD || TARGET_FLOAT128_TYPE)
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
{
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (5 preceding siblings ...)
2023-06-21 17:41 ` bergner at gcc dot gnu.org
@ 2023-06-21 20:31 ` bergner at gcc dot gnu.org
2023-06-21 20:34 ` bergner at gcc dot gnu.org
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-06-21 20:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (6 preceding siblings ...)
2023-06-21 20:31 ` bergner at gcc dot gnu.org
@ 2023-06-21 20:34 ` bergner at gcc dot gnu.org
2023-06-21 23:19 ` segher at gcc dot gnu.org
2023-06-22 13:49 ` dje at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: bergner at gcc dot gnu.org @ 2023-06-21 20:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #7)
> 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
Sorry, I shouldn't call these "regressions", since they FAIL on the unpatched
--without-long-double-128 build too. I just noticed them while scanning the
log files and thought I should mention them.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (7 preceding siblings ...)
2023-06-21 20:34 ` bergner at gcc dot gnu.org
@ 2023-06-21 23:19 ` segher at gcc dot gnu.org
2023-06-22 13:49 ` dje at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: segher at gcc dot gnu.org @ 2023-06-21 23:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #4)
> 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
> attribute aligned? Thoughts?
Maybe just some vector type? Those have 128-bit alignment even with
-mno-altivec,
right?
> gcc.target/powerpc/pr85657-3.c
> gcc.target/powerpc/signbit-1.c
> pr85657-3.c:38:20: error: unknown type name ‘__ibm128’; did you mean
> ‘__int128’?
>
> 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?
It always should, yes. Always. Unconditionally.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
` (8 preceding siblings ...)
2023-06-21 23:19 ` segher at gcc dot gnu.org
@ 2023-06-22 13:49 ` dje at gcc dot gnu.org
9 siblings, 0 replies; 11+ messages in thread
From: dje at gcc dot gnu.org @ 2023-06-22 13:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101002
--- Comment #10 from David Edelsohn <dje at gcc dot gnu.org> ---
Please be careful about the effect on AIX. AIX defaults to long-double-64.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-06-22 13:49 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-09 20:18 [Bug testsuite/101002] New: Some powerpc tests fail with -mlong-double-64 meissner at gcc dot gnu.org
2021-06-10 15:17 ` [Bug testsuite/101002] " bergner at gcc dot gnu.org
2021-06-11 20:54 ` segher at gcc dot gnu.org
2021-06-11 20:55 ` segher at gcc dot gnu.org
2023-06-20 21:20 ` bergner at gcc dot gnu.org
2023-06-21 17:30 ` bergner at gcc dot gnu.org
2023-06-21 17:41 ` bergner at gcc dot gnu.org
2023-06-21 20:31 ` bergner at gcc dot gnu.org
2023-06-21 20:34 ` bergner at gcc dot gnu.org
2023-06-21 23:19 ` segher at gcc dot gnu.org
2023-06-22 13:49 ` dje at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).