[Bug d/106832] New: Missing powerpc64le-linux support for D

[Bug d/106832] New: Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

            Bug ID: 106832
           Summary: Missing powerpc64le-linux support for D
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

When GCC is configured on powerpc64le-linux against glibc 2.26 or later (but in
theory also on older glibcs through libquadmath), there is full support for
IEEE 754 quad (on power8 in software, on power9 through hw support), so I don't
see why D shouldn't be supported in that case.
The current state is that for C/C++ and glibc 2.32 or later (at compile time,
not at GCC configure time) gcc supports both __ibm128 and __ieee128 types and
either of them can be made long double through -mabi=ibmlongdouble or
-mabi=ieeelongdouble switches, default selected at gcc configure time, same
libstdc++.so.6 supports both.
For Fortran (this one is GCC 12 and later only), real(kind=16) can be either
of the IBM extended format (non-IEEE) and IEEE 754 quad, again through
-mabi=ibmlongdouble or -mabi=ieeelongdouble and default selected at gcc
configure time.
On the glibc side, glibc 2.26 adds support for _Float128 (*f128 APIs),
strfromf128 isn't 100% printf replacement but good enough to implement e.g.
what libgfortran needs for IO with a wrapper.
glibc 2.32 adds alternate long double powerpc64le support through __*ieee128
APIs, this one is with full printf replacement.
And libquadmath can be used for older glibcs (*q APIs) as fallback.

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

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

--- Comment #1 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #0)
> When GCC is configured on powerpc64le-linux against glibc 2.26 or later (but
> in theory also on older glibcs through libquadmath), there is full support
> for IEEE 754 quad (on power8 in software, on power9 through hw support), so
> I don't see why D shouldn't be supported in that case.

I haven't tried building D on powerpc64le-linux before, so I don't know what
the failure mode is.  Are you saying we since we have the IEEE128 support in
the compiler, we just need to enable it for D somehow (config file change?) or
that there is some build error when we do build D on powerpc64le-linux?

I'll kick off a build with D enabled to educate myself.

[Bug d/106832] Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the
only target that does:
  power*-*-linux*)
        LIBPHOBOS_SUPPORTED=yes
        LIBDRUNTIME_ONLY=yes
        ;;
I believe the latter means it builds only a small part of libphobos and I think
the reason is the long double stuff (I think D has float/double/real types and
the last one is the largest floating point available).  Now, because IBM
extended and IEEE quad are effectively unordered (neither is subset nor
superset of the other), it is hard to determine which one is actually larger,
but IEEE quad has both higher exponent range and larger mantissa precision for
most of number, it is just those cases closely around values representable in
double that can have higher precision in IBM extended.

[Bug d/106832] Missing powerpc64le-linux support for D

[dan at danny dot cz]

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

--- Comment #3 from Dan Horák <dan at danny dot cz> ---
a couple notes
- you need to start with GCC 11 as GCC 12 needs an existing gdc compiler
- the phobos/dmd standard library seems to support ieeequad type, learned from
ldc, I believe they all share the same standard library
-
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/configure.tgt;h=0063dd23249101b3506106ebbe32f454bcb829fb;hb=HEAD#l47
can go away, seems to build   OK in GCC 11 without the line

[Bug d/106832] Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the IEEE quad support isn't 100%, I see a couple of spots with:
    static if (real.mant_dig > 64)
    {
        pragma(msg, "printFloat tests disabled because of unsupported `real`
format");
    }
where real.mant_dig == 64 is the Intel extended format (and 53 is double
precision).  IEEE quad is 113 though.

[Bug d/106832] Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, for the case where -mabi=ieeelongdouble is the default unless there is
some power* specific configuration in the library that needs to be done perhaps
changing configure.tgt is all we need, but for the case where long double is
IBM extended and only _Float128/__float128 is IEEE quad perhaps some compiler
changes are needed too.  I see stuff like:

  ireal_type_node = build_distinct_type_copy (long_double_type_node);
  TYPE_IMAGINARY_FLOAT (ireal_type_node) = 1;

  else if (TYPE_MAIN_VARIANT (basetype) == long_double_type_node
           || TYPE_MAIN_VARIANT (basetype) == ireal_type_node)
    fmodfn = builtin_decl_explicit (BUILT_IN_FMODL);

etc. (e.g. grep for long_double_type_node or BUILT_IN_[A-Z0-9_]*L etc.) in the
backend.

[Bug d/106832] Missing powerpc64le-linux support for D

[dan at danny dot cz]

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

--- Comment #6 from Dan Horák <dan at danny dot cz> ---
I don't disagree :-) Also the D stdlib code is difficult to readable for me
with all the "version()" sections ...

[Bug d/106832] Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> BTW, for the case where -mabi=ieeelongdouble is the default unless there is
> some power* specific configuration in the library that needs to be done
> perhaps changing configure.tgt is all we need

Though, not sure even about that.
Because the -mabi={ibm,ieee}longdouble switch on the glibc/libm side is done
mostly through __asm redirection in preprocessor, while presumably code emitted
directly by the D compiler just hardcodes library API names (in that case it
should be using __*ieee128 or *f128 instead of *l), similarly for library calls
made from D source using some C compatibility if it has some; library sources
written in C would be fine.

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> BTW, for the case where -mabi=ieeelongdouble is the default unless there is
> some power* specific configuration in the library that needs to be done
> perhaps changing configure.tgt is all we need

Maybe a dumb question, but do we really need to support IBM 128 extended format
at all, regardless of whether long double is IBM128 or IEEE128?  Meaning, since
D is "new" and we have no backwards compatibility issues, can we just say D
only supports IEEE128?  ...assuming doing that can make things easier for us.


(In reply to Dan Horák from comment #3)
> - you need to start with GCC 11 as GCC 12 needs an existing gdc compiler

Yeah, I found that out pretty quickly :-)


> -
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/configure.tgt;
> h=0063dd23249101b3506106ebbe32f454bcb829fb;hb=HEAD#l47 can go away, seems to
> build   OK in GCC 11 without the line

Ah, but this is news to me.  I'll kill my trunk build and remove that line and
re-kick things off.  Thanks!

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the
> only target that does:
>   power*-*-linux*)
>         LIBPHOBOS_SUPPORTED=yes
>         LIBDRUNTIME_ONLY=yes
>         ;;

It's interesting that the power*-*-freebsd*) target stanza doesn't have
"LIBDRUNTIME_ONLY=yes".

[Bug d/106832] Missing powerpc64le-linux support for D

[ibuclaw at gdcproject dot org]

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

--- Comment #10 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Peter Bergner from comment #9)
> (In reply to Jakub Jelinek from comment #2)
> > Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the
> > only target that does:
> >   power*-*-linux*)
> >         LIBPHOBOS_SUPPORTED=yes
> >         LIBDRUNTIME_ONLY=yes
> >         ;;
> 
> It's interesting that the power*-*-freebsd*) target stanza doesn't have
> "LIBDRUNTIME_ONLY=yes".

Someone else tested that port. From what I recall, I did a spot check and saw
that IBM128 is only supported on AIX, Darwin, and
Linux-with-long-double-format=ibm.  For all other Power ports, it's IEEE128 by
default.

[Bug d/106832] Missing powerpc64le-linux support for D

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't powerpc*-*-freebsd* use IEEE double long double?
grep LONG_DOUBLE_SIZE *
darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
linux64.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
linux.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
rs6000.cc:#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE
rs6000.cc:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64
And, sure, it would be ok to support only IEEE quad as D real for
powerpc*-linux*, but then D can be only supported with -mvsx.  Furthermore,
dunno if D has its own math library or uses libm or both, if it doesn't have
everything on its own, then it would need at least glibc 2.27 or later (the one
with *f128 support) or perhaps 2.32 or which has __*ieee128 support.

[Bug d/106832] Missing powerpc64le-linux support for D

[ibuclaw at gdcproject dot org]

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

--- Comment #12 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Jakub Jelinek from comment #11)
> Doesn't powerpc*-*-freebsd* use IEEE double long double?
> grep LONG_DOUBLE_SIZE *
> darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> linux64.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> linux.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128
> rs6000.cc:#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE
> rs6000.cc:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64
Could be that instead, yeah.

> And, sure, it would be ok to support only IEEE quad as D real for
> powerpc*-linux*, but then D can be only supported with -mvsx.  Furthermore,
> dunno if D has its own math library or uses libm or both, if it doesn't have
> everything on its own, then it would need at least glibc 2.27 or later (the
> one with *f128 support) or perhaps 2.32 or which has __*ieee128 support.
Its sort of both. The core D runtime has libm C bindings (core/stdc/math.d),
whereas the standard runtime implements its own (pure) math library
(std/math/*.d).

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #1)
> I'll kick off a build with D enabled to educate myself.

Ok, I see the following on a powerpc64le-linux build on a system that defaults
to long double == IBM128.  I have access to a Fedora36 box that defaults to
IEEE128 so I'll try a build there too.

/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/package.d:320:5:
error: static assert:  "Only 64-bit, 80-bit, and 128-bit reals are supported
for LittleEndian CPUs"
  320 |     static assert(real.mant_dig == 53 || real.mant_dig == 64
      |     ^
make[5]: *** [Makefile:1289: std/complex.lo] Error 1
make[5]: Leaving directory
'/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos/src'
make[4]: *** [Makefile:484: all-recursive] Error 1
make[4]: Leaving directory
'/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos'
make[3]: *** [Makefile:411: all] Error 2
make[3]: Leaving directory
'/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos'
make[2]: *** [Makefile:23281: all-stage3-target-libphobos] Error 2
make[2]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D'
make[1]: *** [Makefile:28917: stage3-bubble] Error 2
make[1]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D'
make: *** [Makefile:1065: all] Error 2

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner <bergner at gcc dot gnu.org> ---
Similar error on a long double == IEEE128 system:

/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5:
error: static assert  "Only 64-bit, 80-bit, and 128-bit reals are supported for
LittleEndian CPUs"
  281 |     static assert(real.mant_dig == 53 || real.mant_dig == 64
      |     ^

[Bug d/106832] Missing powerpc64le-linux support for D

[ibuclaw at gcc dot gnu.org]

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

ibuclaw at gcc dot gnu.org changed:

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

--- Comment #15 from ibuclaw at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #14)
> Similar error on a long double == IEEE128 system:
> 
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5:
> error: static assert  "Only 64-bit, 80-bit, and 128-bit reals are supported
> for LittleEndian CPUs"
>   281 |     static assert(real.mant_dig == 53 || real.mant_dig == 64
>       |     ^
Looks like you configured for IBM128 to me.

[Bug d/106832] Missing powerpc64le-linux support for D

[dan at danny dot cz]

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

--- Comment #16 from Dan Horák <dan at danny dot cz> ---
Peter, what stage is it? A build on Fedora rawhide/ppc64le in the
releases/gcc-11 branch using

"./configure --enable-languages=d --enable-bootstrap
--with-long-double-format=ieee"

together with

@@ -44,7 +44,7 @@ case "${target}" in
        ;;
   power*-*-linux*)
        LIBPHOBOS_SUPPORTED=yes
-       LIBDRUNTIME_ONLY=yes
+#      LIBDRUNTIME_ONLY=yes
        ;;
   riscv*-*-linux*)
        LIBPHOBOS_SUPPORTED=yes

finished successfully.

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #17 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #15)
> (In reply to Peter Bergner from comment #14)
> > Similar error on a long double == IEEE128 system:
> > 
> > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5:
> > error: static assert  "Only 64-bit, 80-bit, and 128-bit reals are supported
> > for LittleEndian CPUs"
> >   281 |     static assert(real.mant_dig == 53 || real.mant_dig == 64
> >       |     ^
> Looks like you configured for IBM128 to me.

Bah, you are correct.  I forgot I needed to add an explicit configure option to
get the IEEE128 default.  I'll kick it off again!  Thanks!

[Bug d/106832] Missing powerpc64le-linux support for D

[kalevlember at gmail dot com]

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

--- Comment #18 from Kalev Lember <kalevlember at gmail dot com> ---
If it helps in any way, I have a copr at
https://copr.fedorainfracloud.org/coprs/kalev/gdc_bootstrap/ that has GCC 12
bootstrapped on ppc64le for F36 (but built with LIBDRUNTIME_ONLY=yes").

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #19 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #17)
> Bah, you are correct.  I forgot I needed to add an explicit configure option
> to get the IEEE128 default.  I'll kick it off again!  Thanks!

Ok, my Fedora36 (ie, a default IEEE128 system) bootstrap using
--with-long-double-format=ieee (and LIBDRUNTIME_ONLY=yes removed) completed
with no errors and this is my gdc testsuite results, which looks pretty good to
me (ie, vast majority of gdc tests pass).  I can look into the few errors here,
but after I look into the IBM128 default system build issue.

                === gdc tests ===


Running target unix
FAIL: gdc.dg/Wbuiltin_declaration_mismatch1.d    (test for warnings, line 10)
FAIL: gdc.dg/torture/gdc309.d   -O0  execution test
FAIL: gdc.dg/torture/gdc309.d   -O0 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O1  execution test
FAIL: gdc.dg/torture/gdc309.d   -O1 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O2  execution test
FAIL: gdc.dg/torture/gdc309.d   -O2 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -O3  execution test
FAIL: gdc.dg/torture/gdc309.d   -O3 -g  execution test
FAIL: gdc.dg/torture/gdc309.d   -Os  execution test
FAIL: gdc.dg/torture/gdc309.d   -Os -g  execution test
UNRESOLVED: gdc.test/runnable/constfold.d   compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/constfold.d -shared-libphobos   compilation
failed to produce executable
FAIL: gdc.test/runnable/xtest46.d   execution test
FAIL: gdc.test/runnable/xtest46.d -shared-libphobos   execution test
FAIL: gdc.test/runnable/xtest46_gc.d   execution test
FAIL: gdc.test/runnable/xtest46_gc.d -shared-libphobos   execution test

                === gdc Summary ===

# of expected passes            11442
# of unexpected failures        15
# of unresolved testcases       2
# of unsupported tests          442
/home/bergner/gcc/build/gcc-fsf-master-lang-D/gcc/gdc  version 13.0.0 20220916
(experimental) (GCC)

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-09-17
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #20 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #13)
> Ok, I see the following on a powerpc64le-linux build on a system that
> defaults to long double == IBM128.
> 
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/package.d:
> 320:5: error: static assert:  "Only 64-bit, 80-bit, and 128-bit reals are
> supported for LittleEndian CPUs"
>   320 |     static assert(real.mant_dig == 53 || real.mant_dig == 64

So going back to my IBM128 build, I see that libphobos does have some code
relating to mant_dig == 106 which is IBM128/IBM double-double, including in the
file that's ICEing here due to the assert.  I've patched two asserts to allow
IBM128 and I'm re-kicking off a bootstrap and regtest.  It might be that the
only problem the asserts needed updating?  We'll see.

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #21 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #20)
> So going back to my IBM128 build, I see that libphobos does have some code
> relating to mant_dig == 106 which is IBM128/IBM double-double, including in
> the file that's ICEing here due to the assert.  I've patched two asserts to
> allow IBM128 and I'm re-kicking off a bootstrap and regtest.  It might be
> that the only problem the asserts needed updating?  We'll see.

For the record, this is what I'm testing with:
diff --git a/libphobos/configure.tgt b/libphobos/configure.tgt
index 0063dd23249..e78688010ed 100644
--- a/libphobos/configure.tgt
+++ b/libphobos/configure.tgt
@@ -44,7 +44,6 @@ case "${target}" in
        ;;
   power*-*-linux*)
        LIBPHOBOS_SUPPORTED=yes
-       LIBDRUNTIME_ONLY=yes
        ;;
   riscv*-*-linux*)
        LIBPHOBOS_SUPPORTED=yes
diff --git a/libphobos/src/std/math/package.d
b/libphobos/src/std/math/package.d
index 19982ec216a..d0752032d1f 100644
--- a/libphobos/src/std/math/package.d
+++ b/libphobos/src/std/math/package.d
@@ -318,13 +318,14 @@ do
 version (LittleEndian)
 {
     static assert(real.mant_dig == 53 || real.mant_dig == 64
-               || real.mant_dig == 113,
+                 || real.mant_dig == 106 || real.mant_dig == 113,
       "Only 64-bit, 80-bit, and 128-bit reals"~
       " are supported for LittleEndian CPUs");
 }
 else
 {
-    static assert(real.mant_dig == 53 || real.mant_dig == 113,
+    static assert(real.mant_dig == 53 || real.mant_dig == 106
+                 || real.mant_dig == 113,
     "Only 64-bit and 128-bit reals are supported for BigEndian CPUs.");
 }

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #22 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #21)
> For the record, this is what I'm testing with:

So we get farther, but ICE again at:
/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.d:1104:9:
error: static assert:  "Not implemented for this architecture"
 1104 |         static assert(0, "Not implemented for this architecture");
      |         ^
/home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.d:981:19:
note: instantiated from here: ‘expImpl!real’
  981 |     return expImpl(x);
      |                   ^

Looking at expImpl(), it has implementations for all of the float types except
for IBM128.  Maybe just need to add support for that???

[Bug d/106832] Missing powerpc64le-linux support for D

[bergner at gcc dot gnu.org]

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

--- Comment #23 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #22)
> Looking at expImpl(), it has implementations for all of the float types
> except for IBM128.  Maybe just need to add support for that???

A few other places as well:

libphobos/src/std/math/exponential.d:
...
    else // static if (F.realFormat == RealFormat.ibmExtended)
    {
        assert(0, "frexp not implemented");
    }
...
    else // static if (F.realFormat == RealFormat.ibmExtended)
    {
        assert(0, "ilogb not implemented");
    }

and... libphobos/src/std/math/operations.d:
    else // static if (F.realFormat == RealFormat.ibmExtended)
    {
        assert(0, "nextUp not implemented");
    }

[Bug d/106832] Missing powerpc64le-linux support for D

[ibuclaw at gdcproject dot org]

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

--- Comment #24 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Peter Bergner from comment #22)
> (In reply to Peter Bergner from comment #21)
> > For the record, this is what I'm testing with:
> 
> So we get farther, but ICE again at:
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.
> d:1104:9: error: static assert:  "Not implemented for this architecture"
>  1104 |         static assert(0, "Not implemented for this architecture");
>       |         ^
> /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/exponential.
> d:981:19: note: instantiated from here: ‘expImpl!real’
>   981 |     return expImpl(x);
>       |                   ^
> 
> Looking at expImpl(), it has implementations for all of the float types
> except for IBM128.  Maybe just need to add support for that???

I'd imagine all static asserts would be hit, so a lot more than that - floor,
tan, sin, cos, pow, etc... - some of which are not exactly trivial to implement
for the IBM format (I've looked at it on a couple occasions over the last
decade).

std/math/algebraic.d:696:            static assert(0);
std/math/exponential.d:1104:        static assert(0, "Not implemented for this
architecture");
std/math/exponential.d:1241:            static assert(0, "No exp() tests for
real type!");
std/math/exponential.d:1514:        static assert(0);
std/math/exponential.d:1590:        static assert(0, "no coefficients for
expm1()");
std/math/exponential.d:1906:        static assert(0);
std/math/exponential.d:1976:        static assert(0, "no coefficients for
exp2()");
std/math/exponential.d:2804:    else static assert(false, "Floating point type
real not supported");
std/math/hardware.d:764:        static assert(false, "Not implemented for this
architecture");
std/math/hardware.d:879:        static assert(false, "Not implemented for this
architecture");
std/math/hardware.d:896:            static assert(false, "Not implemented for
this architecture");
std/math/operations.d:925:        static assert(false, "Not implemented for
this architecture");
std/math/operations.d:1792:            static assert(false, "Floating point
type `" ~ F.realFormat ~ "` not supported.");
std/math/package.d:418:            static assert(false, "No traits support for
" ~ T.stringof);
std/math/package.d:482:        static assert(false, "No traits support for " ~
T.stringof);
std/math/rounding.d:698:            static assert(false, "real type not
supported by lrint()");
std/math/rounding.d:953:        static assert(false, "Not implemented for this
architecture");
std/math/traits.d:305:        static assert(false, "Not implemented for this
architecture");
std/math/trigonometry.d:305:        static assert(0);
std/math/trigonometry.d:381:        static assert(0, "no coefficients for
tan()");
std/math/trigonometry.d:758:        static assert(0, "no coefficients for
atan()");

[Bug d/106832] Missing powerpc64le-linux support for D

[ibuclaw at gdcproject dot org]

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

--- Comment #25 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Iain Buclaw from comment #24)
> I'd imagine all static asserts would be hit, so a lot more than that -
> floor, tan, sin, cos, pow, etc... - some of which are not exactly trivial to
> implement for the IBM format (I've looked at it on a couple occasions over
> the last decade).
Some could be helped along by just returning the result of libm functions
instead of implementing them inline, but then the C function declarations would
need the same attributes as std.math - notably many libm bindings in the
core.stdc.math module are not annotated with `pure`.