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

            Bug ID: 120304
           Summary: SPARC lacks __float128 support
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: ebotcazou at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    jsm28 at gcc dot gnu.org, redi at gcc dot gnu.org
  Target Milestone: ---
            Target: sparc*-*-*

Created attachment 61439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61439&action=edit
Proposed patch

Initially, libgcobol needed __float128 support to build.  Since SPARC lacks
that, but has 128-bit IEEE long double (at least according to the psABI), I
tought this might be easy to add, so I gave it a try.

The basics proved easy enough, and I'm attaching my current patch.  However,
there are/were some issues that need investigation first:

* I initially tried aliasing __float128 to _Float128, but that broke the
  libstdc++ build:

In file included from
/vol/gcc/src/git/gcc-iains/libstdc++-v3/include/precompiled/stdc++.h:57:
/var/gcc/cobol/11.4-gcc-64/sparcv9-sun-solaris2.11/libstdc++-v3/include/limits:2096:12:
error: redefinition of ‘struct std::numeric_limits<_Float128>’
 2096 |     struct numeric_limits<__float128>
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~

  So I went for aliasing long double instead, just like HP-UX/ia64.

* While Solaris/SPARC follows the psABI and uses 128-bit long double,
  Linux/sparc64 and NetBSD/sparc differ, requiring -mlong-double-128.
  On Linux/sparc64 this doesn't work with -m32 either since the 32-bit libgcc
  lacks e.g. __multc3, resulting in many link failures.

* With this patch, there are several remaining testsuite failures, both on
  Solaris/sparc and Linux/sparc64:

+FAIL: gcc.dg/torture/float128-mul-underflow.c   -O0  execution test
[...]
+FAIL: gcc.dg/torture/float128-truncdf-underflow.c   -O0  execution test
[...]
+FAIL: gcc.dg/torture/float128-truncsf-underflow.c   -O0  execution test
[...]

  at all optimization levels.  As it seems, they all abort for the same reason:

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/torture/float128-mul-underflow.c
17          abort ();

  i.e.

  if (fetestexcept (FE_UNDERFLOW))
    abort ();

  I don't yet know what's going on here.

Reply via email to