[Bug testsuite/101002] Some powerpc tests fail with -mlong-double-64

["bergner at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?