[Mips] out of range PC16 fixup when linking the Zig compiler for some target triples

[alexrp]

Seen with:

• mips64el-linux-gnuabin32 (statically linked musl, hard float)

The following triples link successfully, however:

• mips-linux-gnueabi (dynamically linked glibc, soft float)
• mips-linux-gnueabihf (dynamically linked glibc, hard float)
• mips-linux-musleabi (statically linked musl, soft float)
• mips-linux-musleabihf (statically linked musl, hard float)
• mipsel-linux-gnueabi (dynamically linked glibc, soft float)
• mipsel-linux-gnueabihf (dynamically linked glibc, hard float)
• mipsel-linux-musleabi (statically linked musl, soft float)
• mipsel-linux-musleabihf (statically linked musl, hard float)
• mips64-linux-gnuabi64 (dynamically linked glibc, hard float)
• mips64-linux-gnuabin32 (dynamically linked glibc, hard float)
• mips64-linux-muslabi64 (statically linked musl, hard float)
• mips64-linux-muslabin32 (statically linked musl, hard float)
• mips64el-linux-gnuabi64 (dynamically linked glibc, hard float)
• mips64el-linux-muslabi64 (statically linked musl, hard float)
• mips64el-linux-muslabin32 (statically linked musl, hard float)

This started happening with LLVM 19. We subsequently switched our baseline CPU for MIPS to mips32r2/mips64r2, which alleviated the problem. However, it started happening again with the upgrade to LLVM 20.

Example steps to reproduce:

$ git clone git@github.com:ziglang/zig-bootstrap.git
$ cd zig-bootstrap
$ ./build mips64el-linux-gnuabin32 baseline

On a modern x86 machine, this will take ~15 minutes to build the compiler for the current machine, and then another ~15 minutes to (attempt to) build the compiler that runs on mips64el-linux-gnuabin32.

Note that this repo builds and uses a "vendored" LLVM, LLD, and Clang as its purpose is to allow low-effort bootstrapping of Zig for any system. The vendored code here is ~equivalent to the tagged LLVM 20.1.2 release, with only some trivial build system patches on top to avoid building unnecessary fluff.

[llvmbot]

@llvm/issue-subscribers-backend-mips

Author: Alex Rønne Petersen (alexrp)

Seen in:

• mips-linux-gnueabi ziglang/zig-bootstrap#195 (dynamically linked glibc, soft float)
• mips-linux-gnueabihf ziglang/zig-bootstrap#196 (dynamically linked glibc, hard float)
• mips64-linux-muslabi64 ziglang/zig-bootstrap#192 (statically linked musl, hard float)

The following triples link successfully, however:

• mips-linux-musleabi (statically linked musl, soft float)
• mips-linux-musleabihf (statically linked musl, hard float)
• mipsel-linux-gnueabi (dynamically linked glibc, soft float)
• mipsel-linux-gnueabihf (dynamically linked glibc, hard float)
• mipsel-linux-musleabi (statically linked musl, soft float)
• mipsel-linux-musleabihf (statically linked musl, hard float)
• mips64-linux-gnuabi64 (dynamically linked glibc, hard float)
• mips64el-linux-gnuabi64 (dynamically linked glibc, hard float)
• mips64el-linux-musl (statically linked musl, hard float)

If there is a pattern here, I don't see it. 🙁

This started happening with LLVM 19, but it's possible that's just a coincidence. It's unclear to me if the bug is in LLVM or LLD.

Example steps to reproduce:

$ git clone git@<!-- -->github.com:ziglang/zig-bootstrap.git
$ cd zig-bootstrap
$ ./build mips64-linux-musl baseline

On a modern x86 machine, this will take ~15 minutes to build the compiler for the current machine, and then another ~15 minutes to (attempt to) build the compiler that runs on mips64-linux-musl.

Note that this repo builds and uses a "vendored" LLVM, LLD, and Clang as its purpose is to allow low-effort bootstrapping of Zig for any system. The vendored code here is ~equivalent to the tagged LLVM 19.1.0 release, with only some trivial build system patches on top to avoid building unnecessary fluff.

Still trying to see if I can reduce this to a more manageable repro, but for now, this is the best I've got.

[alexrp]

We've since bumped Zig's baseline CPU for MIPS from mips32/mips64 to mips32r2/mips64r2 to be in line with Clang. After doing that, none of these linker errors reproduce anymore. That seems unlikely to be a coincidence. 🤔

(This means that to reproduce, you now have to do ./build mips64-linux-muslabi64 mips64 instead of ./build mips64-linux-muslabi64 baseline.)

[alexrp]

We've since bumped Zig's baseline CPU for MIPS from mips32/mips64 to mips32r2/mips64r2 to be in line with Clang. After doing that, none of these linker errors reproduce anymore. That seems unlikely to be a coincidence. 🤔

Unfortunately, this is now happening again after the LLVM 20 upgrade, and even with the target CPU being mips32r2/mips64r2. Only for mips64el-linux-gnuabin32 this time, however.

I've updated the original issue with the currently working/failing triples.

[brad0]

Looking at build logs for failed package builds I see we see this here with Clang on OpenBSD/mips64. It looks like both with C++ code.

http://build-failures.rhaalovely.net/mips64/2025-04-10/astro/gnuastro.log
http://build-failures.rhaalovely.net/mips64/2025-04-10/databases/mariadb.log

We're using LLVM 16 at the moment, though soon to update to 19.