Snapshot 85043c1c crashes; same-SHA native build does not

[hongtaihu]

Pack: aarch64-ubuntu2004-manyclangs-202508
Commit: 85043c1c146fd5658ad4c5b5138e58994333e645

Input:

  void test() {}

clang++ -fsyntax-only -std=c++23 test.cpp

Behavior:
manyclangs snapshot of this commit crashes.
A native build of the same commit does not.

[peterwaller-arm]

Thanks for the report! Agent assisted writeup, for the record:

Manyclangs rewrites CMake’s generated build rules to use relative paths. That rewrite gives some generated headers names such as ../build/tools/…, while their producer rules use tools/…. These refer to the same file on disk, but Ninja treats them as different dependency nodes. When a commit changes a generated header, Ninja can regenerate it without rebuilding all its consumers, leaving a compiler assembled from inconsistent objects. This explains how an LLVM revision can crash in Manyclangs while a clean build works.

The consequence of this is that there are some snapshots in the history which are inconsistently assembled. This can lead to the crashes like the one you observed or some subtle semantic inconsistencies vs a clean build. In the case the snapshot you named this gives a crash. You can git bisect skip it or build it from scratch.

I expect to have this fixed for the 202609 pack onwards; and one day we may have manyclangs-v1 packs as well for which this should be fixed. Already published snapshots will not be fixed.

A brief estimate shows as many as 1 in 10 snapshots may be affected by the stale objects. Not all of them will have significant problems but some commits may appear as 'off by one' in a bisect if their semantic effects are delayed.