I agree getting to a hotspot without C++ undefined behavior is very hard. Organizations like Google like to have control over all their software, including the toolchain, and want both high performance and standards compliance, enforced via tools like ubsan https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html. Full employment for engineers like me who try to bridge the 2 worlds. I'd like to see hotspot stop using the -fno-strict-aliasing curtch, replacing it with union and/or may_alias, but this is a serious investment. Here are my type-punning notes: #---------------------------------------------------------------- # -fstrict-aliasing, union, memcpy, C99, C++. #---------------------------------------------------------------- https://blog.regehr.org/archives/959 http://dbp-consulting.com/tutorials/StrictAliasing.html C99 allows type punning via members of a union, and all known C++ compilers allow it, but strictly speaking not permitted by the C++ standard. 85. If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning). This might be a trap representation. Doing type punning via memcpy really goes against low-level programmer instinct - we really have to trust the compiler to optimize away the memcpy library call! gcc (what about clang?) has the may_alias attribute https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html