Prior to this change, Fedora and RHEL 9 on s390x would incorrectly pass
the HAVE_CXX11_ATOMIC check. As a consequence, the rest of Ceph would
fail to link because of missing atomic methods "__atomic_load_16",
"__atomic_store_16", "__atomic_compare_exchange_16".
Mark this method so that it is not optimized out, even with LTO. With
this change, s390x properly fails HAVE_CXX11_ATOMIC and falls back to
HAVE_LIBATOMIC.
Move the "BuildRequires: libatomic" RPM line out from the seastar+fedora
conditional and into the main fedora+rhel conditional so that the
HAVE_LIBATOMIC check will pass.
Fixes: https://tracker.ceph.com/issues/54514
Fixes: https://tracker.ceph.com/issues/56492
Co-authored-by: Kaleb S. Keithley <kkeithle@redhat.com>
Signed-off-by: Ken Dreyer <kdreyer@redhat.com>
we have following error when trying to compile the C++ source
file on mipsel:
/usr/bin/c++ -DHAVE_CXX11_ATOMIC -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -g1 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIE -o CMakeFiles/cmTC_9f34f.dir/src.cxx.o -c /<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx
/<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:15:44: error: template argument 1 is invalid
15 | bool atomic16(std::atomic<unsigned __int128> *ptr)
| ^
/<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:15:44: error: template argument 1 is invalid
/<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:15:44: error: template argument 1 is invalid
/<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:15:44: error: template argument 1 is invalid
/<<PKGBUILDDIR>>/obj-mipsel-linux-gnu/CMakeFiles/CMakeTmp/src.cxx:15:47: error: ‘ptr’ was not declared in this scope
15 | bool atomic16(std::atomic<unsigned __int128> *ptr)
| ^~~
the compiler was GCC 11.2.0.
in this change, instead of detecting the architecture, check for
the macro of `__SIZEOF_INT128__`, which is respected by GCC and Clang.
so it's more readable. also, instead of using the `unsigned __int128`
type provided as a GCC extension, use a struct to mimic the use case
of boost::lockfree library.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
it's reported that a mips64el build host is able to pass the test of
CheckCxxAtomic without linking against libatomic, while librbd.so
fails to link due to failures like
/usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_store_16'
/usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_load_16'
/usr/bin/ld: ../../../lib/librbd.so.1.16.0: undefined reference to `__atomic_compare_exchange_16'
so we have to check the existence of __atomic_load_16 instruction on
mips architecture.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
Commit d1b9d14324 added a check for
16-byte atomics without library support on IBM Z. Unfortunately
it turns out this test only works correctly when the test case
is built without optimization. (This is normally true, but it
may not be the case when passing explicit CXXFLAGS to cmake.)
The underlying reason is that GCC may choose to use either an
inline implementation of the 16-byte atomics or library calls,
depending on whether or not it is able to prove the atomic
variable is properly aligned. At -O0 it is never able to prove
that, but at higher optimization levels it depends on the complexity
of the expression (in particular, whether GCC can track down the
definition of the underlying object).
As the test case uses a very simple expression, it may happen that
this test can be built without requiring library support, but some
of the "real" uses of atomics in Ceph code cannot. This defeats
the whole purpose of the test at configure time.
Fixed by making the access pattern in the test more complex, so
that the test fails even at high optimization levels.
Fixes: https://tracker.ceph.com/issues/43747
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
On IBM Z the Boost tagged pointer implementation cannot use
"pointer compression" as there are no unused bits in an address;
the whole 64-bit address space is available to user space code.
Instead, Boost uses 16-byte atomics. This is always supported
on IBM Z, but depending on the particular compiler (version)
it may require linking against libatomic. The existing checks
in CheckCxxAtomic.cmake do not catch this, however, as they only
test for (up to) 8-byte atomic support.
Fixed by adding a test for 16-byte atomic support on IBM Z.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
for instance, GCC-8 on riscv64 does not offer atomic ops like
__atomic_fetch_or_1, so we need to link against libatomic to get access
to these symbols.
Signed-off-by: Kefu Chai <kchai@redhat.com>
