powerpc64-unknown-linux-musl target data-layout does not match LLVM, making the target useless

[saethlin]

cargo +nightly build -Zbuild-std=core --target=powerpc64-unknown-linux-musl

error: internal compiler error: compiler/rustc_codegen_llvm/src/context.rs:178:13: data-layout for target
`powerpc64-unknown-linux-musl`,
`E-m:e-Fi64-i64:64-n32:64-S128-v256:256:256-v512:512:512`, differs from
LLVM target's `powerpc64-unknown-linux-musl` default layout,
`E-m:e-Fn32-i64:64-n32:64-S128-v256:256:256-v512:512:512`

(wrapped by hand to make the problem clear)

The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM.

While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine):

If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

---

I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to powerpc-unknown-linux-gnu or the powerpc64le- targets.

[alex]

Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like @panekj is the maintainer with musl.

Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like llvm/llvm-project@8d2e9fc may be what broke this.

[saethlin]

powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.

[davidtwco]

So I'm running into this in #118708, the relevant code in LLVM is:

  // If the target ABI uses function descriptors, then the alignment of function
  // pointers depends on the alignment used to emit the descriptor. Otherwise,
  // function pointers are aligned to 32 bits because the instructions must be.
  if ((T.getArch() == Triple::ppc64 && !T.isPPC64ELFv2ABI())) {
    Ret += "-Fi64";
  } else if (T.isOSAIX()) {
    Ret += is64Bit ? "-Fi64" : "-Fi32";
  } else {
    Ret += "-Fn32";
  }

(source)

  /// Tests whether the target 64-bit PowerPC big endian ABI is ELFv2.
  bool isPPC64ELFv2ABI() const {
    return (getArch() == Triple::ppc64 &&
            ((getOS() == Triple::FreeBSD &&
              (getOSMajorVersion() >= 13 || getOSVersion().empty())) ||
             getOS() == Triple::OpenBSD || isMusl()));
  }

(source)

We get e-Fn32-i64 rather than e-Fi64-i64 because of the musl-ness of the target.

As far as I can tell, this would have been the case since function pointer alignments were added to data layouts for PowerPC targets in LLVM, and the definition of isPPC64ELFv2ABI hasn't changed since that was introduced.

I think we just got this value wrong in #114048.

[vidraj]

I have trawled the issue tracker and I cannot find any evidence that this target is in use

Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.