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
