https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829
--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- From a discussion on IRC: What's the general story on lock policies? Are environments supposed to support all three? (if possible) no. it's something only used in std::shared_ptr, and generally entirely invisible to users What's supposed to happen if one (can't be supported)? most people will only ever use the default one, which gets chosen according to the target _S_single always works, it just isn't thread-safe But that's surely bogus if detected dynamically if _S_atomic doesn't work for a given target then users should not try to use it (ie based on the CPU architecture _S_single is only ever the default if gcc is built with --disable-threads Ok, so we can ignore that one, then yeah but seems that mutex and atomic can't be a compile time choice; it must be selected at configure time based on the base architecture used at that point yes (or you have to ensure every translation unit in the program uses the same choice) (including the libstdc++.so linked to) But we can't guarantee that if you use the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_<N> macros since those are dependent on certain patterns being enabled in the back-end of the compiler, and that's dependent on the architecture. yep I think it would be better to move the _atomic _mutex check into configure and create a new macro based on the result of a test performed then at least then a build of the library would always work with code compiled with that compiler agreed (even if it isn't quite as efficient if you normally have a later rev of the architecture) OK, I'll put that in the PR so IIUC, if gcc is configured for armv7 (and so chooses the _S_atomic policy) and then somebody builds their code with -mcpu=armv5 they will need to link to libatomic to get the necessary atomic ops if that's correct, it seems fine to me. when this lock policy stuff was invented we didn't have libatomic, and so some arches simply didn't have atomics, period Yes, provided the compiler correctly falls back into the library code in that case. now we can punt to libatomic, so can use _S_atomic for any arch with a libatomic implementation It would be a bit odd-ball to build for ARMv5 if your library is v7 anyway (you'd still need a v7 device to run it on) yep So I won't loose too much sleep over that combination people seem to do that though maybe just for testing, I don't know Probably for that ok, so not a real case we need to support good Not performant, anyway Do you mind if I just paste the above directly into the PR?
