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?
