Re: HAVE_CXX11_ATOMIC vs libatomic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 2, 2023 at 9:14 AM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
>
> On Mon, Oct 2, 2023 at 7:53 AM Ken Dreyer <kdreyer@xxxxxxxxxx> 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@xxxxxxx
> > To unsubscribe send an email to dev-leave@xxxxxxx
> >
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx




[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux