simde: clang 12 + ppc64le: ninja build error: __float128 is not supported on this target

Awesome, thanks! I was actually able to skip most of this since I could use ppc64le hardware; just had to use registry.fedoraproject.org/fedora:35-ppc64le instead of fedora:35. I was able to confirm that it’s a libc++ issue:

[root@d7b05e55a726 ~]# cat test.cpp 
#include <complex>

int main(void) { return 0; }

[root@d7b05e55a726 ~]# clang -o test test.cpp
In file included from test.cpp:1:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/complex:45:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/sstream:38:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/istream:38:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/ios:40:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/bits/char_traits.h:39:
In file included from /usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/bits/stl_algobase.h:63:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/ext/numeric_traits.h:222:38: error: __float128 is not supported on this target
    struct __numeric_traits_floating<__ieee128>
                                     ^
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/ext/numeric_traits.h:230:29: error: __float128 is not supported on this target
    struct __numeric_traits<__ieee128>
                            ^
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../include/c++/11/ext/numeric_traits.h:231:40: error: __float128 is not supported on this target
    : public __numeric_traits_floating<__ieee128>
                                       ^
3 errors generated.
[root@d7b05e55a726 ~]# clang --version
clang version 12.0.0 (Fedora 12.0.0-0.7.rc3.fc35)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Debian has binfmt, but I haven’t figured out how to get it working from inside a Docker container 😦. I’ll have to try it with Fedora.

Anyways, I use Fedora for my desktop, so I’ll definitely keep this bookmarked 😃

Unfortunately the s/390x VM is temporary; it’s a free trial.

Ah okay.

I think the problem is the GNU C++ Library (which I believe is in the GCC source tree); the work-around would be to use LLVM’s C++ library instead.

I was able to confirm that it’s a libc++ issue:

$ find /usr/include/ -name complex.h
/usr/include/complex.h
/usr/include/c++/10/tr1/complex.h
/usr/include/c++/10/complex.h

$ rpm -qf /usr/include/complex.h
glibc-headers-x86-2.32-4.fc33.noarch

$ rpm -qf /usr/include/c++/10/tr1/complex.h
libstdc++-devel-10.2.1-9.fc33.x86_64

$ rpm -qf /usr/include/c++/10/complex.h
libstdc++-devel-10.2.1-9.fc33.x86_64

I can see the /usr/include/complex.h file comes from the glibc-headers RPM sub package in the glibc RPM package [1], and the other comlex.h files come from libstdc++-devel sub package in the gcc RPM package [3] on my Fedora 33.

So, maybe I will try to report it with a small reproducer to the Fedora glibc issue ticket [1] or the GNU libc upstream project [2] at first. If it is not proper, maybe ask it on Fedora gcc [3] or the gcc upstream project [4].

[1] https://src.fedoraproject.org/rpms/glibc/ [2] http://www.gnu.org/software/libc/

[3] https://src.fedoraproject.org/rpms/gcc/ [4] http://gcc.gnu.org

This also showed me how I can get recent gcc/clang versions installed on s/390x (the VM I have access to is running RHEL 8), so I should be able to start working on #733 right away

That’s nice. It’s really great if we can use the s/390x machine too as CI running machine with Cirrus CI.

Unfortunately the s/390x VM is temporary; it’s a free trial.

You could use LLVM’s libc++ (add -stdlib=libc++ to CXXFLAGS), I think that would do the trick. You may also want to report the issue upstream; just including triggers it so I have a feeling it will get addressed pretty quickly.

Let me try something. Does this issue comes from the libc++ in clang-12, right? The upstream to report is the clang project?

I think the problem is the GNU C++ Library (which I believe is in the GCC source tree); the work-around would be to use LLVM’s C++ library instead.

Though I forget I shared you about this, in the past, I had a talk about the qemu-user-static and binfmt_misc in the Fedora event: Flock 2019 (https://github.com/multiarch/qemu-user-static/issues/90). My slide might be good to know the topic. The binfmt file installed on the host machine also works in the space of container. That’s the trick to run different architecture’s container.

Ooohh, I’ll have to try that. Thanks for sharing!

This also showed me how I can get recent gcc/clang versions installed on s/390x (the VM I have access to is running RHEL 8), so I should be able to start working on #733 right away ☺

OK! Thanks for checking it! So, seeing this ticket is closed, you fixed this issue on the master branch, right?

No, sorry but I don’t think there is anything I can do. AFAIK there is nothing we can do to work around <complex> in C++ (we can, and do, avoid <complex.h> in C, but the same tricks don’t work in C++). If you (or anyone else) wants to try, the revelant code is in simde/simde-complex.h. I’d be really happy to accept a patch which allows us to avoid <complex>, even if only on some compilers.

You could use LLVM’s libc++ (add -stdlib=libc++ to CXXFLAGS), I think that would do the trick. You may also want to report the issue upstream; just including <complex> triggers it so I have a feeling it will get addressed pretty quickly.

I don’t mind leaving this open to track any upstream issues.

Ah I think if you have ppc64le hardware, you can just run the VM without qemu like this.

$ docker run --rm -t registry.fedoraproject.org/fedora:35 uname -m

or

$ docker run --rm -t registry.fedoraproject.org/fedora:35-ppc64le uname -m

@nemequ Thanks for the checking!

I tried to test, but docker pull fedora:35 doesn’t seem to work for ppc64le (it looks like it’s only available for arm64 and amd64). I don’t suppose you know an easier way to test than installing a VM and running it in qemu? I have access to ppc64le hardware, but f35 is tricky…

I was able to use Fedora official container repository’s registry.fedoraproject.org/fedora:35-ppc64le on QEMU now! Here is the repo: https://registry.fedoraproject.org/repo/fedora/tags/

Let me share the steps.

First you need to have a Linux host. Maybe you have it.

$ uname -m
x86_64

If you have the Fedora, CentOS (maybe >= 7) or RHEL (>= 7), and you can install the qemu-user-static RPM, the RPM installs /proc/sys/fs/binfmt_misc/qemu-ppc64le file. And confirm the line: flags: F exists.

$ cat /proc/sys/fs/binfmt_misc/qemu-ppc64le
enabled
interpreter /usr/bin/qemu-ppc64le-static
flags: F
offset 0
magic 7f454c4602010100000000000000000002001500
mask ffffffffffffff00fffffffffffffffffeffff00

If you do not have above Linux distro, the easy way to install the above binfmt_misc file is to use this tool: https://github.com/dbhi/qus . I do not know how to install the binfmt_misc file on Debian based distro. If you are using docker, just replace the following command’s podman with docker. And maybe sudo is not necessary in case of docker.

$ sudo podman run --rm --privileged aptman/qus -s -- -p ppc64le

The above command is only to install the following file.

$ cat /proc/sys/fs/binfmt_misc/qemu-ppc64le
enabled
interpreter /qus/bin/qemu-ppc64le-static
flags: F
offset 0
magic 7f454c4602010100000000000000000002001500
mask ffffffffffffff00fffffffffffffffffeffff00

Then I confirmed that the QEMU emulation works.

$ podman run --rm -t registry.fedoraproject.org/fedora:35-ppc64le uname -m
ppc64le

Then I could install clang 12.

$ podman run --rm -it registry.fedoraproject.org/fedora:35-ppc64le bash
[root@0b26c2f39c41 /]# dnf install clang

[root@0b26c2f39c41 /]# rpm -q clang
clang-12.0.0-0.7.rc3.fc35.ppc64le

[root@0b26c2f39c41 /]# clang --version
clang version 12.0.0 (Fedora 12.0.0-0.7.rc3.fc35)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

If you like, I can contribute this case to one of this repo’s CIs.