mlir: async runtime uses atomics but does not link with libatomic

[jpalus]

MLIR's async runtime uses atomics: https://github.com/llvm/llvm-project/blob/d86a206f06a51c12a9fcf2c20199f4e819751c0c/mlir/lib/ExecutionEngine/AsyncRuntime.cpp#L76

but appears not to link against libatomic on arch that require it: https://github.com/llvm/llvm-project/blob/d86a206f06a51c12a9fcf2c20199f4e819751c0c/mlir/lib/ExecutionEngine/CMakeLists.txt#L139-L147

Resulting in unresolved symbols when building ie for armv6:

undefined reference to `__atomic_fetch_add_8'

[llvmbot]

@llvm/issue-subscribers-mlir-core

[joker-eph]

This is part of the C++ standard, I believe it should be handled by default by the C++ toolchain.

[jpalus]

Does not seem to be the case:

#include <atomic>

int main() {
	std::atomic<int64_t> c(0);
	c.fetch_add(1, std::memory_order_relaxed);
}

$ g++ -march=armv6 -mfloat-abi=hard -mfpu=vfp -marm test.cpp -o test
/usr/bin/ld: /home/users/builder/tmp/ccMuRNQ2.o: in function `main':
test.cpp:(.text+0x3c): undefined reference to `__atomic_fetch_add_8'
collect2: error: ld returned 1 exit status

$ g++ --version
g++ (PLD-Linux) 12.1.0 20220508 (release)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Linking against libatomic fixes the issue. Also building for armv7-a works without additional lining likely due to more atomic operations available on ARMv7.

Note that libatomic linking is already common in LLVM codebase ie: lld: https://github.com/llvm/llvm-project/blob/768a251587e41e9298658b2bbcc5846e46580d77/lld/Common/CMakeLists.txt#L3-L5 clangd: https://github.com/llvm/llvm-project/blob/768a251587e41e9298658b2bbcc5846e46580d77/clang-tools-extra/clangd/support/CMakeLists.txt#L14-L16

[jpalus]

Situation got considerably worse with release 15. Now same issue affects multiple libraries and binaries. I suppose atomic operations are now part of some common header file. My only workaround is to just link libatomic whenever libLLVM is linked and delegate dropping libatomic if not needed to -Wl,--as-needed.

[jpalus]

1a14436c35b4738a22554cc4a7349bfcf3ceea78 solves it by adding libatomic linking together with libLLVM if target arch needs it. Issue can be closed.