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