On 31.07.2020 17:01, Puetz Kevin A wrote:
There's no __sync_bool_compare_and_swap_16 in ARMv8.0 (or even with ARMv8.1, support wasn't added until until GCC 10).
This of course broke our builds when it was added; for now I'd been working around it with the attached patch, which substitutes the -latomic __atomic_compare_exchange_16, which is allowed to be based on a lock if there's no lockfree implementation (e.g. the specified -march or GCC lack support for the ARMv8.1 CASP* instructions).
I was waiting to hear back from our BSP guys whether we'd eventually get support on the final hardware/toolchain or not before raising this upstream, to see know if I had an issue that needed a "real" fix or just a short-term impediment (in which case I had a viable workaround in the meantime).
But if you're moving it into external API too, then it seems like it's time to at least point out what I've learned.
Microsoft only promises InterlockedCompareExchange128 on amd64; It's nice to offer it anywhere an underlying compiler intrinsic exists, but that needs to test defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16). And I think RtlInterlocked*SList needs some kind of fallback. What I did with -latomic seems sane, but should get a ./configure check since you wouldn't need to link -latomic if the compiler has the intrinsic.
Oh, I see, I didn't know it's already broken on aarch64. FWIW, I just wanted to fix a warning on clang msvcrt target and while doing that, I generalized the solution. We can wait with that for aarch64 solution.
Depending on -latomic may be problematic in PE builds. If I read libatomic source right, libatomic resorts to using lock in this case (pthread_mutex_lock or equivalent, depending on host). We could probably just add a variant of affected RtlInterlocked*SList* functions that would use critical section instead of interlocked operations.
Thanks,
Jacek