← board

Track T: c-conformance shards time out under full parallel load (false REDs)

Symptom

tools/testmgr.py --tier full intermittently reports

  FAIL     test-c-conformance-arm32#shard3/6   conformance   39.7s  tools/run_c_conformance.sh
  FAIL     test-c-conformance-aarch64#shard3/6 conformance   44.5s  tools/run_c_conformance.sh

and the same job run on its own passes in 8.2 s:

tools/testmgr.py --tier full --job 'test-c-conformance-arm32#shard3/6'
  PASS ... 8.2s

So the shard takes ~5x longer under the full 16-way parallel matrix than alone, and crosses the timeout. #shard3 is the usual victim; test-aarch64#…sysopen and test-c-conformance-aarch64#shard1 have flaked the same way (exit=124).

Not a compiler regression — verified

Suspecting my own change (anonymous bit-fields, which stops those structs being opaque and so does MORE layout work), I timed the same shard with the PINNED pre-change compiler: 8.2 s, identical. The slowdown is contention, not codegen.

Why it matters

A false RED is worse than a slow test: it burns a full-matrix rerun (~5 min each), and it trains the reader to shrug at REDs — exactly the reflex that lets a real regression through. Three of four full runs went RED this way tonight.

Suggested fixes (Track T's call)

Log