Hi David, On Tue, Oct 26, 2021 at 10:27:40AM +0100, David CARLIER wrote: > Hi Willy, > > Ok with your changes suggestions even tough it seemed to work fine > with the raspberry/clang combination
I have no doubt it works, given that this can rely on the fallback part. It's just that I don't want to see build failures on odd compiler/hw just because the toolchain doesn't provide 128-bit atomics for example. With LSE there's the casp instruction so we know by definition that this is supported, which is why I'm fine with testing both INT128 and ATOMICS. > (failure might be due to apple oddities here) That's pretty possible indeed. But I suspect that the issue comes from %H0/%H2 which are constraints for register pairs. I had difficulties figuring the right ones, so probably that clang/llvm uses different ones and fails on these, making it logical to evince clang from this part. > but anyway let s fall back to the builtin regardless. Yep that's the point. > Btw __atomic_compare_exchange wants a mutable parameter as third > argument thus the cast to avoid the spurious build warnings. Ah interesting. I can confirm that after installing clang on an ARM I'm indeed seeing a warning there. Actually the problem comes from a bug in the gcc documentation! It's written "type *desired" for this argument instead of "const type *desired". The compiler obviously uses it as a const as this part must absolutely not be modified. However clang probably (rightfully) matched the doc and doesn't have the const there, resulting in this warning. I changed that part for a simpler version relying on the other variant __atomic_compare_exchange_n() which takes a value on input. We know we can have one now since we've already checked for INT128 support. I verified that it produces the same code before and after. I'm taking your patch now. Thanks, Willy
