On Mon, Oct 2, 2023 at 9:14 AM Gregory Farnum <gfarnum(a)redhat.com> wrote:
On Mon, Oct 2, 2023 at 7:53 AM Ken Dreyer <kdreyer(a)redhat.com> wrote:
Hi folks,
In Reef and newer, all RHEL versions on all arches have
HAVE_CXX11_ATOMIC=false, so they all build with -latomic.
Is this expected?
It certainly surprises me. I built our libatomic usage some 12-14
years ago, and I don't remember if I or somebody else did the switch
to CXX11 atomic, but I would have thought we were fully on that
solution by now. It should be faster, supported on more architectures,
etc. But perhaps there's some issue I've forgotten?
-Greg
This was niggling at me so I didn't dive all the way in, but I do see
in the git history that the test for inbuilt atomics
(cmake/modules/CheckCxxAtomic.cmake) got a lot more complicated to
deal with 16-byte atomics on different architectures, which seemed to
be defeating our detection. Kefu changed it most recently to fix
mipsel builds; but perhaps it inadvertently(? hopefully it's a
detection bug, not a real issue?) caused the check to fail on
perfectly normal x86/64 builds?
-Greg
>
> Obviously it "works", but I thought newer compilers (like RHEL 9's
> gcc-c++-8.5.0-18.el8) should result in HAVE_CXX11_ATOMIC=true. Maybe I
> have that backwards, and we should expect HAVE_CXX11_ATOMIC to be
> false for all newer compilers? Am I mis-understanding the purpose of
> CheckCxxAtomic.cmake?
>
> Is HAVE_CXX11_ATOMIC better than libatomic for performance? Or something else?
>
> The reason I ask is that we've fixed a couple corner-case bugs (eg
> s390x) here over the past few years. Reef+ can build on modern GCC
> with s390x now that we've fixed these bugs, but I'm wondering if the
> consequence of always setting HAVE_CXX11_ATOMIC=false now is
> intentional or desirable.
> _______________________________________________
> Dev mailing list -- dev(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io
>