Using C++11+ in hotspot

Martin Buchholz martinrb at google.com
Wed Aug 8 19:51:39 UTC 2018


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


More information about the workshop-discuss mailing list