Until C++17 (inclusive), a default-constructed std::atomic object can, officially, only be initialized with a call to std::atomic_init, for which QBasicAtomic doesn't have API. It is even unclear whether zero-initialization of static and thread-local objects will cause the object to be initialized. Seeing as we can't rely on malloc's zero-initialization to properly initialize std::atomic objects (and therefore QBasicAtomic ones), and because it's the right thing to do, from a [basic.life] POV, anyway, port to placement new instead. The realloc() feels fishy, seeing as it reallocs a struct that contains an atomic variable (which we don't mark as Q_RELOCATABLE_TYPE even for our own types), but assume that part it ok, and in-place construct only if realloc() was passed nullptr (so is equivalen to malloc()). A final solution for this can probably only be implemented when we can depend on C++20's atomic_ref, which decouples the underlying object from the atomic operations performed on it. Rename the ref_ member to m_ref to catch any uses of the variable, incl. since removed ones in older branches. Amends 812a611dc05e5facd036856625ccb9274fdcb117 (which ported from QtPrivate::RefCount to QBasicAtomicInt; I didn't check whether QtPrivate::RefCount had a similar problem, because that commit is already much older than what I can pick back to at this point). Task-number: QTBUG-137465 Pick-to: 6.10 6.9 6.8 6.5 Change-Id: I188e05d09e20e0820af7cf1cbb651afa860bb9d6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>