JDK-8238281 changed the gcc implementation of the HotSpot offset_of macro to make it simply expand into a use of the standard offsetof macro. To make that work, -Wno-invalid-offsetof was added to the build options.
That change to offset_of was made in the belief that the old definition was a workaround for old versions of gcc. But that isn't correct.
offsetof with a non-POD type is undefined behavior in C++98. C++11 relaxed the restriction to allow standard-layout types. C++17 changed offsetof with a non-standard-layout type to be "conditionally supported", which is more or less effectively UB for portable code.
Contrary to what was said in the RFR for
JDK-8238281, we should not be considering eliminating offset_of and just using offsetof directly. offset_of is the HotSpot portability shim to let us knowingly do something that is potentially problematic but we claim we know what we're doing. The fact that gcc warns about problematic offsetof uses (unless -Wno-invalid-offsetof) is a good thing, because it helps keep us honest about using that portability shim. (This is similar in concept to
JDK-8214976.) (There are a couple of direct uses of offsetof in os_perf_solaris.cpp.)
The part of
JDK-8238281 related to offset_of should be reverted.
JDK-8300080 offset_of for GCC/Clang exhibits undefined behavior and is not always a compile-time constant
