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

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

[meissner at gcc dot gnu.org]

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

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

[bergner at gcc dot gnu.org]

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.

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

[segher at gcc dot gnu.org]

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

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

[segher at gcc dot gnu.org]

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 :-)

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

[bergner at gcc dot 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?

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

[bergner at gcc dot gnu.org]

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)

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

[bergner at gcc dot gnu.org]

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
        {

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

[bergner at gcc dot gnu.org]

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

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

[bergner at gcc dot gnu.org]

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.

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

[segher at gcc dot gnu.org]

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.

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

[dje at gcc dot gnu.org]

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.