From 9bf056e3f759ef87aca9c1f481ac3fb28e6599b9 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen Date: Mon, 15 Mar 2010 14:37:41 +0100 Subject: fix aliasing issue in node_construct() invisible so far, but the next patch uncovers it. this could be possibly optimized for more compilers. however, i found no way to ask msvc whether it is doing an optimized build. Reviewed-by: thiago --- src/corelib/tools/qlist.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/corelib/tools/qlist.h b/src/corelib/tools/qlist.h index dc8c849..e3b8e1b 100644 --- a/src/corelib/tools/qlist.h +++ b/src/corelib/tools/qlist.h @@ -377,7 +377,15 @@ Q_INLINE_TEMPLATE void QList::node_construct(Node *n, const T &t) { if (QTypeInfo::isLarge || QTypeInfo::isStatic) n->v = new T(t); else if (QTypeInfo::isComplex) new (n) T(t); +#if (defined(__GNUC__) || defined(__INTEL_COMPILER) || defined(__IBMCPP__)) && !defined(__OPTIMIZE__) + // This violates pointer aliasing rules, but it is known to be safe (and silent) + // in unoptimized GCC builds (-fno-strict-aliasing). The other compilers which + // set the same define are assumed to be safe. else *reinterpret_cast(n) = t; +#else + // This is always safe, but penaltizes unoptimized builds a lot. + else ::memcpy(n, &t, sizeof(T)); +#endif } template -- cgit v0.12