tl;dr: I’ll attempt to address this in the next upload.
Revisiting this, the logs are expired, but I think I finally understand
the problem. This will take a bit of explanation, so strap in (or ignore
this mail)…
I now believe the failure was the rumur-model autopkgtest, though my
previous replies suggest at the time I thought it was the
rumur-run-model autopkgtest. This perhaps explains why Tobi was
confused, when I pointed to an upstream commit that touched a file that
has no interaction with the rumur-model test.
This package uses both the GCC __sync built-ins¹ and the GCC __atomic
built-ins². Either of these may require linking against libatomic,
depending on your platform. However, the rumur-model test just checks a
single __sync built-in does not need libatomic.
On ARM, how these built-ins are lowered (to either inline assembly or a
call to libatomic) depends on the architecture. In armv8.1-a, ARM added
so-called “Large System Extensions”, the relevant feature of which to us
is a compare-and-swap instruction. However, GCC only makes use of this
for the __sync built-ins, not the __atomic built-ins.³
The upshot of this is that the rumur-model test could run its __sync
test, conclude libatomic was not needed, then run its actual compilation
which additionally used __atomic and would fail. My hypothesis is that
the ARM buildd workers were a mixture of <armv8.1-a and ≥armv8.1-a,
which would explain why we were seeing disagreeing results.
Underneath all of this, what the atomics are used for is implementing a
lock-free algorithm. So lowering to a call into libatomic and then
taking a lock somewhat defeats the purpose. Once I realised this was
happening in scenarios on ARM where it could be avoided, I tried to
address this. A first attempt at this crashed GCC.⁴ After working around
this,⁵ I believe I have something that avoids libatomic more reliably.⁶
Of course, none of this fixes the check the rumur-model test does that
uses only one __sync built-in, but I think I now understand all the
moving pieces and am capable of fixing this in the next upload.
Tobi, thanks for reporting this, without which I probably never would
have noticed the problem. I am also indebted to Caroline Xu, a Rumur
user. Recent discussion with Caroline finally gave me the clues I needed
to put all this together.
¹ https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
² https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
³ See https://gcc.gnu.org/pipermail/gcc-help/2017-June.txt and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 for a laborious
discussion of why this is.
⁴ https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114310
⁵
https://github.com/Smattr/rumur/commit/28eb088ce8fdd5c039c19d39a4ef6cd85d4ea70f
⁶
https://github.com/Smattr/rumur/commit/adba81cde626901077a1c946dc57446660db47e3
