On 2026-09-07 23:07:41 [+0200], To Emilio Pozuelo Monfort wrote: > On 2026-09-06 23:43:02 [+0200], To Emilio Pozuelo Monfort wrote: > > sense because the symbol is missing. Tomorrow I need to figure out why > > the llvm sees it greater than 1. > > I build something on amdahl that I hope works.
tada! Amdahl built the package. It aborted somewhere at the end and I think during docs (but I did -B so?) but then a retry with -j1 -nc passed. I am optimistic here. I am attaching the slightly altered patch from what I had on Amdahl and hopefully not fat fingered… I keep the the 30G around in | bigeasy@amdahl:~/llvm unless you don't need it and I can free up. > > > > > Cheers, > > > > > Emilio Sebastian
From: Sebastian Andrzej Siewior <[email protected]> Date: Mon, 7 Sep 2026 22:57:56 +0200 Subject: [PATCH] armel workaround armel is an older ARCH and has no support for built-in atomics. This is what gcc does, sync the behaviour. This is just duct tape which should get the gcc's / libstdc++ futex implementation going. It would be better to get ::hasBuiltinAtomic() to not report that it has atomic ops but it does not appear to me that it can or I missed it. A side effect is probably that cross compilation will get this wrong (but we probably don't do this). Signed-off-by: Sebastian Andrzej Siewior <[email protected]> --- clang/lib/Frontend/InitPreprocessor.cpp | 7 +++++++ 1 file changed, 7 insertions(+) --- a/clang/lib/Frontend/InitPreprocessor.cpp +++ b/clang/lib/Frontend/InitPreprocessor.cpp @@ -321,6 +321,13 @@ static const char *getLockFreeValue(unsi // width will be inlined as lock-free operations. // Note: we do not need to check alignment since _Atomic(T) is always // appropriately-aligned in clang. +#if defined(__ARMEL__) + if (__ARM_ARCH <= 5) { + /* armel has no atomics */ + return "1"; + } + /* armhf uses he generic code */ +#endif if (TI.hasBuiltinAtomic(TypeWidth, TypeWidth)) return "2"; // "always lock free" // We cannot be certain what operations the lib calls might be
