Hmm, upstream posted no announcement nor link from the web :-/ BTW, I expect the rebuild amount is too high for direct merge to master.

I don't think we need to wait for that, but the amount of rebuilds is high, so it probably shouldn't go directly to master anyway.

https://github.com/llvm/llvm-project/compare/llvmorg-7.0.1..llvmorg-7.1.0

Yep, it's entirely the official fix version of the patch we were using-- well, that and bits involved in changing the version number xD.

So definitely looks good, and indeed should be sent to staging (which I just fixed now). Thanks!

We're seeing this failure on aarch64:

https://hydra.nixos.org/job/nixpkgs/staging-next/llvm_7.aarch64-linux

We're seeing this failure on aarch64:

https://hydra.nixos.org/job/nixpkgs/staging-next/llvm_7.aarch64-linux

Well that's no good, sorry!

Thoughts so far:

• If needed, we can disable llvm-exegesis / don't provide libpfm: neat utility but compared to having a working clang/libLLVM is by comparison unimportant.
• It's strange this started happening with the update? The only change, AFAICT, we weren't already using is the new minor version number (and propagating it through the code). Take a look: https://github.com/llvm/llvm-project/compare/llvmorg-7.0.1..llvmorg-7.1.0 .
• Our aarch64 builder has an awesome number of cores, which sometimes causes problems we don't see elsewhere. I don't see that being the cause here, though...

Oh, that's right-- this has happened before and disappeared, apparently?

#56245

Dunno, but thanks for the ping!

So looking at the test in question... it looks like it wants to check basic perf events fire, but it tests with the execution of a literally empty lambda (?!):

https://github.com/llvm/llvm-project/blob/1feaee52ff70948747251d83690de3ee35709a61/llvm/unittests/tools/llvm-exegesis/PerfHelperTest.cpp#L26

Perhaps it's intentionally testing the edge case ("ensure at least one event is triggered")?

Brainstorming-style, do we know that this builder supports performance counters? Cloud infrastructure often has limited support for this, no clue what the situation is with aarch64 but that might be worth checking.

Alright, I think I have something! cc @grahamc re:arm builders and Packet-relatedness.
This is a bit of a long-shot but here we go...

• Looks like the builder is a Packet C2 Large Arm
• According to the specs on that page, it's running an Ampere eMAG.
• Awesomely, Ampere has this page on this model and their upstreaming support for it
  • Needs 4.19, or patches?

... do we know what kernel we're running on these? ^_^

EDIT: last successful build was on a different type machine, which is promising! Builder was packet-t2a5-qc-centriq-1. ( https://hydra.nixos.org/build/92610201#tabs-buildsteps )

Ah ok! I just saw that the version change and assumed it was new. It looks like it's been happening on a few past builds as well

@dtzWill Another issue that may not be directly related to this update but looks to be caused by the version bump:

https://hydra.nixos.org/build/92930990/nixlog/3/tail

--- stderr
llvm-config: error: libLLVM-7.1.dylib is missing
thread 'main' panicked at 'command did not execute successfully: "/nix/store/5ffmj0j7px7xwawrb25bwxxhab633gvg-llvm-7.1.0/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "aarch64" "amdgpu" "arm" "asmparser" "bitreader" "bitwriter" "hexagon" "instrumentation" "interpreter" "ipo" "linker" "lto" "mcjit" "mips" "msp430" "nvptx" "powerpc" "sparc" "systemz" "webassembly" "x86"
expected success, got: exit code: 1', src/build_helper/lib.rs:134:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Maybe some patch in the llvm script needs to be updated?

@matthewbauer I'm already working on that one.

The performance counters test failure (issue #56245) also occurred when I tried to build llvm 7.0.1 on a Raspberry Pi 3.