What's missing for sparc64 in Clang? We have Clang on sparc64 in Debian Ports.

My memory here is fuzzy because I'm very much not interested in Sparc, but, as far as technical shortcomings: there are integrated-assembler (ias) pieces missing; ld.lld support is extremely incomplete; it's missing a working stack unwinder. If you look for Sparc work in Clang upstream, it becomes obvious that it's not active.

The biggest thing missing was interest (and associated time and resources). People have had 6-12 months to step up if they wanted to work on moving platforms off of GCC4.2.1, and unlike for every other tier 2-3 arch formerly on GCC, no one showed up to work on Sparc.

> We have Clang on sparc64 in Debian Ports.

As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang?

Here's some more context around missing pieces:

https://svnweb.freebsd.org/base?view=revision&revision=35446...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233405

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236839

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239851

Initially, we were building Clang only. But we're also now building Clang using itself, i.e. a stage2 compiler.

There are issues though when building Clang with Clang with Gold as the linker. It works fine with BFD though.

We are not building the whole archive with Clang though. But all Rust packages are built on sparc64 as well which uses the LLVM backend.

Thanks for the links. I'll look into them. Maybe we find some more bugs than can be fixed on SPARC in LLVM/Clang.

Edit: From your first link:

> "Contemporary GCC does not build and there is currently no indication that anyone is going to address these issues."

That's odd. We're building all GCC versions on Debian/sparc64. It's still a maintained backend in GCC, after all.