https://bugs.openjdk.java.net/browse/JDK-8032045 suggests turning on
_FORTIFY_SOURCE to enable additional compiler and runtime bounds
checks and the like. This is presently only being done in debug (fast
and slow). Unfortunately, that's a problem.

_FORTIFY_SOURCE is documented to only do anything useful when
optimization level is >= 1. See "man feature_test_macros" or here:
https://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html

slowdebug doesn't provide that level of optimization, so
_FORTIFY_SOURCE is at best useless for slowdebug builds.

And in fact, it is worse than useless, and is actually broken when
using a recent version of glibc (starting with glibc-2.16?, definitely
a problem with in 2.18), which now tests the optimization level when
_FORTIFY_SOURCE is defined and produces a #warning if the optimization
level is insufficient. [Presumably this is to prevent the user's
request for additional checking from being silently ignored.] The
code for this check and warning is in /usr/include/features.h. This
warning, combined with -Werror being on in at least some places,
results in a build failure on affected platforms when building
hotspot.

I also got a similar build failure for a fastdebug build.

I further note that slowdebug is now setting _FORTIFY_SOURCE=2. The
documentation for that says "more checking is added, but some
conforming programs might fail." That does not seem to me to be an
desirable behavior to request for most debugging situations; spending
time first diagnosing some bogus fortify failure and figuring out how
to turn that feature off is not going to be much fun. It might be
worth providing as an additional configuration option that a developer
could use in a specific situation, but not as a default.