[Bug target/104253] New: libgcc missing __floatdiif

[Bug target/104253] New: libgcc missing __floatdiif

[murphyp at linux dot vnet.ibm.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

            Bug ID: 104253
           Summary: libgcc missing __floatdiif
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: murphyp at linux dot vnet.ibm.com
                CC: bergner at gcc dot gnu.org, meissner at gcc dot gnu.org
  Target Milestone: ---

When compiling something which uses the __ibm128 type, an instrinsic function
call is generated which is not satisfied at link time. E.g foo.c:

#include <stdio.h>
#include <stdlib.h>

int main(int a, char **v)
{
        long d = strtol(v[1],0,0);
        __ibm128 i = d;
        printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
        return 0;
}

gcc -O2 foo.c -o foo:
/usr/bin/ld: /tmp/ccuWW1m0.o: in function `main':
foo.c:(.text.startup+0x2c): undefined reference to `__floatdiif'
collect2: error: ld returned 1 exit status

This happens on a ppc64le machine running fedora rawhide, gcc -v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64le-redhat-linux/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: ppc64le-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.0.1-20220118/obj-ppc64le-redhat-linux/isl-install
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-offload-defaulted --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-long-double-format=ieee --with-cpu-32=power8
--with-tune-32=power8 --with-cpu-64=power8 --with-tune-64=power8
--build=ppc64le-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220118 (Red Hat 12.0.1-0) (GCC)

[Bug libgcc/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-01-26
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Michael Meissner <meissner at gcc dot gnu.org> ---
In addition to __floatdiif not being in libgcc, if you build a recent trunk, it
exposes a second issue:

-ltcden3-lp5-> /home/meissner/fsf-install-ppc64le/trunk/bin/gcc -O2 pr-104253.c
during RTL pass: expand
pr-104253.c: In function ‘main’:
pr-104253.c:8:9: internal compiler error: in copy_to_mode_reg, at explow.cc:652
    8 |         printf("%a
%a\n",__builtin_unpack_ibm128(i,0),__builtin_unpack_ibm128(i,1));
      |        
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x10408cab copy_to_mode_reg(machine_mode, rtx_def*)
        /home/meissner/fsf-src/trunk/gcc/explow.cc:652
0x10f28837 rs6000_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
        /home/meissner/fsf-src/trunk/gcc/config/rs6000/rs6000-call.cc:5834
0x1043811f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        /home/meissner/fsf-src/trunk/gcc/expr.cc:11536
0x10446e7b store_expr(tree_node*, rtx_def*, int, bool, bool)
        /home/meissner/fsf-src/trunk/gcc/expr.cc:6087
0x1044af77 expand_assignment(tree_node*, tree_node*, bool)
        /home/meissner/fsf-src/trunk/gcc/expr.cc:5819
0x10285cbb expand_call_stmt
        /home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:2829
0x10285cbb expand_gimple_stmt_1
        /home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:3864
0x10285cbb expand_gimple_stmt
        /home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:4028
0x1028dd93 expand_gimple_basic_block
        /home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6069
0x1028ff27 execute
        /home/meissner/fsf-src/trunk/gcc/cfgexpand.cc:6795
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug libgcc/104253] libgcc missing __floatdiif

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I wouldn't expect any *if libgcc function names to be used, because "tf" 
libgcc names are supposed to refer to the ibm128 format and "kf" names are 
supposed to refer to the IEEE binary128 format, regardless of which format 
is actually TFmode inside the compiler.

Probably much the same issue as this bug: building

_Complex double ic __attribute__ ((mode (IC)));
void test_ic (void) { ic /= ic; ic *= ic; }

with -mabi=ieeelongdouble produces spurious __divic3 and __mulic3 
references (should be __divtc3 and __multc3).

[Bug libgcc/104253] libgcc missing __floatdiif

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Agreed.

[Bug libgcc/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #4 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 52306
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52306&action=edit
Patch to use the correct names for __ibm128 converts if long double is IEEE
128-bit

The problem was internally there are 3 types for 128-bit floating point:
TFmode -- mode for the type long double
IFmode -- mode for __ibm128 if long double is IEEE 128-bit
KFmode -- mode for __float128

There was not a conversion function specified to convert between IFmode and
other modes, so the machine independent portion of the compiler created a name
with 'if' in it.

This patch specifies the names for the conversion functions to use the
traditional TF modes.

[Bug libgcc/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |meissner at gcc dot gnu.org

--- Comment #5 from Michael Meissner <meissner at gcc dot gnu.org> ---
The other issue that I mentioned in note #2 is likely a different issue when
-mabi=ibmlongdouble is used.  I didn't have the patch to automatically use IEEE
128-bit if the compiler used to build stage1 also used IEEE 128-bit.

[Bug target/104253] libgcc missing __floatdiif

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Michael Meissner from comment #4)
> Created attachment 52306 [details]
> Patch to use the correct names for __ibm128 converts if long double is IEEE
> 128-bit
> 
> The problem was internally there are 3 types for 128-bit floating point:
> TFmode -- mode for the type long double
> IFmode -- mode for __ibm128 if long double is IEEE 128-bit
> KFmode -- mode for __float128
> 
> There was not a conversion function specified to convert between IFmode and
> other modes, so the machine independent portion of the compiler created a
> name with 'if' in it.
> 
> This patch specifies the names for the conversion functions to use the
> traditional TF modes.

None of these functions except for the DI <-> IF (called tf) functions actually
exist in libgcc though.

[Bug target/104253] libgcc missing __floatdiif

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Conversion from __ibm128 to float/double etc. are done differently, and for si
<-> if named tf we want to use di instead.
So, shouldn't we just add
+      set_conv_libfunc (sfix_optab, DImode, mode, "__fixtfdi");
+      set_conv_libfunc (ufix_optab, DImode, mode, "__fixunstfdi");
+
+      set_conv_libfunc (sfloat_optab, mode, DImode, "__floatditf");
+      set_conv_libfunc (ufloat_optab, mode, DImode, "__floatunditf");
and nothing else?

[Bug target/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #8 from Michael Meissner <meissner at gcc dot gnu.org> ---
Yes, you are right.  I didn't remember which functions were generated by the
compiler, but I just did all of the conversion functions.

[Bug target/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52306|0                           |1
        is obsolete|                            |

--- Comment #9 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 52312
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52312&action=edit
Replacement patch for fixing the integer <-> __ibm128 conversions if long
double is IEEE 128-bit.

Replacement for patch #2 that only modifies the names that are used.

[Bug target/104253] libgcc missing __floatdiif

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
LGTM, passed testing for me, are you going to post it?

[Bug target/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #11 from Michael Meissner <meissner at gcc dot gnu.org> ---
The patch has been posted, I'm awaiting approval.
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589469.html

BTW, the copy_to_mode_reg bug I mentioned earlier goes away with the patch.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:16b65b08484237cc2845c4f5c4f15efe3a43a32c

commit r12-7233-g16b65b08484237cc2845c4f5c4f15efe3a43a32c
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Mon Feb 14 17:42:14 2022 -0500

    Use correct names for __ibm128 if long double is IEEE 128-bit.

    If you are on a PowerPC system where the default long double is IEEE
    128-bit (either through the compiler option -mabi=ieeelongdouble or via
    the configure option --with-long-double-format=ieee), GCC used the wrong
    names for some of the conversion functions for the __ibm128 type.

    Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit,
    instead of TFmode when long double is IBM 128-bit.  This patch adds the
    missing conversions to prevent the 'if' name from being used.

    In particular, before the patch, the conversions used were:

        IFmode to DImode signed:    __fixifdi       instead of __fixtfdi
        IFmode to DImode unsigned   __fixunsifti    instead of __fixunstfti
        DImode to IFmode signed:    __floatdiif     instead of __floatditf
        DImode to IFmode unsigned:  __floatundiif   instead of __floatunditf

    2022-02-14  Michael Meissner  <meissner@the-meissners.org>

    gcc/
            PR target/104253
            * config/rs6000/rs6000.cc (init_float128_ibm): Update the
            conversion functions used to convert IFmode types.

    gcc/testsuite/
            PR target/104253
            * gcc.target/powerpc/pr104253.c: New test.

[Bug target/104253] libgcc missing __floatdiif

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk.  Mike mentioned we need backports.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Michael Meissner
<meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:a1984704a7c2b9be8c89b3381e9c453ccbc5e7bf

commit r11-9638-ga1984704a7c2b9be8c89b3381e9c453ccbc5e7bf
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Sat Mar 5 11:19:43 2022 -0500

    Use correct names for __ibm128 if long double is IEEE 128-bit.

    If you are on a PowerPC system where the default long double is IEEE
    128-bit (either through the compiler option -mabi=ieeelongdouble or via
    the configure option --with-long-double-format=ieee), GCC used the wrong
    names for some of the conversion functions for the __ibm128 type.

    Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit,
    instead of TFmode when long double is IBM 128-bit.  This patch adds the
    missing conversions to prevent the 'if' name from being used.

    In particular, before the patch, the conversions used were:

        IFmode to DImode signed:    __fixifdi       instead of __fixtfdi
        IFmode to DImode unsigned   __fixunsifti    instead of __fixunstfti
        DImode to IFmode signed:    __floatdiif     instead of __floatditf
        DImode to IFmode unsigned:  __floatundiif   instead of __floatunditf

    2022-03-05  Michael Meissner  <meissner@the-meissners.org>

    gcc/
            PR target/104253
            * config/rs6000/rs6000.c (init_float128_ibm): Update the
            conversion functions used to convert IFmode types.  Backport
            change from 2022-02-14 made on the master branch.

    gcc/testsuite/
            PR target/104253
            * gcc.target/powerpc/pr104253.c: New test.  Backport
            change from 2022-02-14 made on the master branch.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Michael Meissner
<meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:b3531eb23a23be0219c6ab0ff85110c2648086e6

commit r10-10487-gb3531eb23a23be0219c6ab0ff85110c2648086e6
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Sat Mar 5 20:14:44 2022 -0500

    Use correct names for __ibm128 if long double is IEEE 128-bit.

    If you are on a PowerPC system where the default long double is IEEE
    128-bit (either through the compiler option -mabi=ieeelongdouble or via
    the configure option --with-long-double-format=ieee), GCC used the wrong
    names for some of the conversion functions for the __ibm128 type.

    Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit,
    instead of TFmode when long double is IBM 128-bit.  This patch adds the
    missing conversions to prevent the 'if' name from being used.

    In particular, before the patch, the conversions used were:

        IFmode to DImode signed:    __fixifdi       instead of __fixtfdi
        IFmode to DImode unsigned   __fixunsifti    instead of __fixunstfti
        DImode to IFmode signed:    __floatdiif     instead of __floatditf
        DImode to IFmode unsigned:  __floatundiif   instead of __floatunditf

    2022-03-05  Michael Meissner  <meissner@the-meissners.org>

    gcc/
            PR target/104253
            * config/rs6000/rs6000.c (init_float128_ibm): Update the
            conversion functions used to convert IFmode types.  Backport
            change made to the master branch on 2022-02-14.

    gcc/testsuite/
            PR target/104253
            * gcc.target/powerpc/pr104253.c: New test.  Backport change made
            to the master branch on 2022-02-14.

[Bug target/104253] libgcc missing __floatdiif

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Michael Meissner <meissner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Michael Meissner <meissner at gcc dot gnu.org> ---
Backports done to gcc 10 and gcc 11 branches.  PR closed.

[Bug target/104253] libgcc missing __floatdiif

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
The test fails on VxWorks, where there is no 128-bit long double:

cc1: warning: The '-mfloat128' option may not be fully supported

so it looks like a DejaGNU selector is missing.

[Bug target/104253] libgcc missing __floatdiif

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #18 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #17)
> The test fails on VxWorks, where there is no 128-bit long double:
> 
> cc1: warning: The '-mfloat128' option may not be fully supported
> 
> so it looks like a DejaGNU selector is missing.

It's a dg-run test case, but the dg-require only uses ppc_float128_sw.  There
is a ppc_float128_hw which is probably what Mike meant to use?

[Bug target/104253] libgcc missing __floatdiif

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #19 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #17)
> The test fails on VxWorks, where there is no 128-bit long double:
> 
> cc1: warning: The '-mfloat128' option may not be fully supported
> 
> so it looks like a DejaGNU selector is missing.

Eric, we don't have access to test VxWorks.  Can you try changing the
dg-require using ppc_float128_sw to ppc_float128_hw and see if that fixes it
for you?

[Bug target/104253] libgcc missing __floatdiif

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #20 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Eric, we don't have access to test VxWorks.  Can you try changing the
> dg-require using ppc_float128_sw to ppc_float128_hw and see if that fixes it
> for you?

Apparently not, so Michael's approach is probably required.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:

https://gcc.gnu.org/g:45fb78c9c456ace1d914c836d15af38ae345b902

commit r12-8052-g45fb78c9c456ace1d914c836d15af38ae345b902
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Thu Apr 7 18:25:17 2022 -0400

    Disable float128 tests on VxWorks, PR target/104253.

    In PR target/104253, it was pointed out the that test case added as part
    of fixing the PR does not work on VxWorks because float128 is not
    supported on that system.  I have modified the three tests for float128 so
    that they are manually excluded on VxWorks systems.  In looking at the
    code, I also added checks in check_effective_target_ppc_ieee128_ok to
    disable the systems that will never support VSX instructions which are
    required for float128 support (eabi, eabispe, darwin).

    2022-04-07   Michael Meissner  <meissner@linux.ibm.com>

    gcc/testsuite/
            PR target/104253
            * lib/target-supports.exp (check_ppc_float128_sw_available): Do
            not run float128 tests on VxWorks.
            (check_ppc_float128_hw_available): Likewise.
            (check_effective_target_ppc_ieee128_ok): Likewise.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86

commit r12-8087-gab0f04e4df1b7b312a4c9fa9b4d675778a0bae86
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Mon Apr 11 12:11:10 2022 -0300

    ppc: testsuite: require target effectively [PR104253]

    The testcase was missing dg- before require-effective-target.

    While at that, I'm also pruning the excess-error warning I got when
    the test failed to be disabled because of the above.  I suppose it
    might be useful for some target variants.


    for gcc/testsuite/ChangeLog

            PR target/104253
            * gcc.target/powerpc/pr104253.c: Add missing dg- before
            require-effective-target.  Prune warning about -mfloat128
            possibly not being fully supported.

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Alexandre Oliva
<aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:20bde90da2ac415d4a06e7a8b2ba770d50385208

commit r11-9810-g20bde90da2ac415d4a06e7a8b2ba770d50385208
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Mon Apr 11 12:11:10 2022 -0300

    ppc: testsuite: require target effectively [PR104253]

    The testcase was missing dg- before require-effective-target.

    While at that, I'm also pruning the excess-error warning I got when
    the test failed to be disabled because of the above.  I suppose it
    might be useful for some target variants.


    for gcc/testsuite/ChangeLog

            PR target/104253
            * gcc.target/powerpc/pr104253.c: Add missing dg- before
            require-effective-target.  Prune warning about -mfloat128
            possibly not being fully supported.

    (cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)

[Bug target/104253] libgcc missing __floatdiif

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Alexandre Oliva
<aoliva@gcc.gnu.org>:

https://gcc.gnu.org/g:3ebf64eaf264e1dcb4e72b77f67308fe58d993f8

commit r10-10530-g3ebf64eaf264e1dcb4e72b77f67308fe58d993f8
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Mon Apr 11 12:11:10 2022 -0300

    ppc: testsuite: require target effectively [PR104253]

    The testcase was missing dg- before require-effective-target.

    While at that, I'm also pruning the excess-error warning I got when
    the test failed to be disabled because of the above.  I suppose it
    might be useful for some target variants.


    for gcc/testsuite/ChangeLog

            PR target/104253
            * gcc.target/powerpc/pr104253.c: Add missing dg- before
            require-effective-target.  Prune warning about -mfloat128
            possibly not being fully supported.

    (cherry picked from commit ab0f04e4df1b7b312a4c9fa9b4d675778a0bae86)