Change:
<ins> //! Tests for target tier policy compliance. //! //! As of writing, only checks that sanity-check assembly test for targets doesn't miss any targets. use crate::walk::{filter_not_rust, walk}; use std::{collections::HashSet, path::Path}; const TARGET_DEFINITIONS_PATH: &str = "compiler/rustc_target/src/spec/targets/"; const ASSEMBLY_TEST_PATH: &str = "tests/assembly/targets/"; const REVISION_LINE_START: &str = "// revisions: "; const EXCEPTIONS: &[&str] = &[ // FIXME: disabled since it fails on CI saying the csky component is missing "csky_unknown_linux_gnuabiv2", "csky_unknown_linux_gnuabiv2hf", ]; pub fn check(root_path: &Path, bad: &mut bool) { let mut targets_to_find = HashSet::new(); let definitions_path = root_path.join(TARGET_DEFINITIONS_PATH); for defn in ignore::WalkBuilder::new(&definitions_path) .max_depth(Some(1)) .filter_entry(|e| !filter_not_rust(e.path())) .build() { let defn = defn.unwrap(); // Skip directory itself. if defn.path() == definitions_path { continue; } let path = defn.path(); let target_name = path.file_stem().unwrap().to_string_lossy().into_owned(); let _ = targets_to_find.insert(target_name); } walk(&root_path.join(ASSEMBLY_TEST_PATH), |_, _| false, &mut |_, contents| { for line in contents.lines() { let Some(_) = line.find(REVISION_LINE_START) else { continue; }; let (_, target_name) = line.split_at(REVISION_LINE_START.len()); targets_to_find.remove(target_name); } }); for target in targets_to_find { if !EXCEPTIONS.contains(&target.as_str()) { tidy_error!(bad, "{ASSEMBLY_TEST_PATH}: missing assembly test for {target}") } } } </ins>

Discussion:
(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 or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
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.