llvmPackages_13: Fix the build on AArch64

[primeos]

The compiler-rt build was failing with:
/build/source/compiler-rt/build/lib/fuzzer/libcxx_fuzzer_aarch64/include/c++/v1/__config:1065:41: error: a destructor cannot be 'constexpr'
1065 | # define _LIBCPP_CONSTEXPR_AFTER_CXX17 constexpr
| ^~~~~~~~~
make[5]: *** [cxx/src/CMakeFiles/cxx_static.dir/build.make:303: cxx/src/CMakeFiles/cxx_static.dir/optional.cpp.o] Error 1
make[2]: *** [lib/fuzzer/CMakeFiles/libcxx_fuzzer_aarch64-build.dir/build.make:80: lib/fuzzer/libcxx_fuzzer_aarch64-stamps/libcxx_fuzzer_aarch64-build] Error 2

See:

• https://hydra.nixos.org/job/nixpkgs/trunk/llvmPackages_13.compiler-rt.aarch64-linux/all
• https://hydra.nixos.org/log/nlcppawcbnpff23mdxxk6ianrwp8p7j7-compiler-rt-libc-13.0.0-rc2.drv

Motivation for this change

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[primeos]

@ofborg build llvmPackages_13

Let's see if this is enough.

[primeos]

Unfortunately it now fails during the linking:

collect2: error: ld returned 1 exit status
make[2]: *** [tools/llvm-shlib/CMakeFiles/LLVM.dir/build.make:308: lib/libLLVM-13.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:33523: tools/llvm-shlib/CMakeFiles/LLVM.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 74%] Linking CXX static library ../../../../lib/libLLVMExegesisX86.a
[ 74%] Built target LLVMExegesisX86
make: *** [Makefile:171: all] Error 2
builder for '/nix/store/x3w4hdzx59wp66j4l6ps29xagawz3dkk-llvm-13.0.0-rc2.drv' failed with exit code 2

I don't have enough time to have a look at it.

[lorenz]

FYI this is because libcxx and compiler-rt have different minimum compiler requirements to core LLVM. As per https://libcxx.llvm.org/#platform-and-compiler-support we need at least GCC 11 to build these, but it looks like you tried with GCC 9.3 and GCC 10.

[queezle42]

Unfortunately it now fails during the linking:

collect2: error: ld returned 1 exit status

Before that message I'm seeing many errors similar to:

[...]/bin/ld: AArch64PBQPRegAlloc.cpp:([...]): undefined reference to `__aarch64_ldadd4_acq_rel'

Cursory research seems to indicate this is caused by -moutline-atomics (docs), which is enabled by default in newer GCCs.

Because the build is targeting the base ARMv8.0 instruction set atomic operations are not guaranteed to be available (they are part of Armv8.1-A), so helpers from libgcc are injected for atomic operations (which then fail to link).

Potential fixes include setting -mno-outline-atomics, targeting a higher version of the instruction set (I'm assuming this wouldn't be acceptable for nixpkgs?) or figuring out what leads to the linker failures.

---

I just tried to build llvm using GCC11 with -mno-outline-atomics (commit). Linking worked, but tests failed:

llvm> LLVM :: CodeGen/ARM/vararg_no_start.ll              Exception in thread Thread-3:
llvm> Traceback (most recent call last):
llvm>   File "/nix/store/8zhpsi47a8v89l23fzplan67gmx7x0b5-python3-3.9.6/lib/python3.9/threading.py", line 973, in _bootstrap_inner
llvm>     self.run()
llvm>   File "/nix/store/8zhpsi47a8v89l23fzplan67gmx7x0b5-python3-3.9.6/lib/python3.9/threading.py", line 910, in run
llvm>     self._target(*self._args, **self._kwargs)
llvm>   File "/nix/store/8zhpsi47a8v89l23fzplan67gmx7x0b5-python3-3.9.6/lib/python3.9/multiprocessing/pool.py", line 576, in _handle_results
llvm>     task = get()
llvm>   File "/nix/store/8zhpsi47a8v89l23fzplan67gmx7x0b5-python3-3.9.6/lib/python3.9/multiprocessing/connection.py", line 256, in recv
llvm>     return _ForkingPickler.loads(buf.getbuffer())
llvm> _pickle.UnpicklingError: invalid load key, '\x00'.

I'll try GCC10 next.

[queezle42]

Tests seem to fail at random points (CodeGen/ARM/vararg_no_start.ll, CodeGen/AMDGPU/add_i1.ll, CodeGen/ARM/vararg_no_start.ll) with the above message, so I'm assuming that's unrelated to the build (maybe it's caused by running in binfmt?).

So the build is probably fine, I just can't verify it. @primeos Can you pick this back up from here?

[queezle42]

I've debugged this with @BBBSnowball for a few more hours. -mno-outline-atomics only masks the underlying issue; the actual issue is that glibc contains a libgcc from the bootstrap tools (which is a GCC 8.3), which doesn't have the relevant helpers. I'm surprised this hasn't caused more problems.

The issue for the problem is #36947.