Defining the _FORTIFY_SOURCE={1 or 2} macro when compiling with gcc enables some checks for buffer overflow when the optimization level is at least 1. See man feature_test_macros(7) for some more details about what this configuration macro does.

Because it only applies with -O1 and higher, this macro isn't useful for (slow)debug builds, which use -O0.

Unfortunately, some care is needed for fastdebug builds.

Because _FORTIFY_SOURCE > 0 only applies with -O1 and higher, some versions of glibc (starting with glibc-2.16) test the optimization level when _FORTIFY_SOURCE is defined, and produce a warning if the optimization level is insufficient. This is to prevent the user's request for additional checking from being silently ignored. See

  https://sourceware.org/bugzilla/show_bug.cgi?id=13979

This check and warning is in /usr/include/features.h. This warning, combined with -Werror being on in at least some places, would result in a build failure on affected platforms when building hotspot if a non-0 _FORTIFY_SOURCE value is used, since there are some files that are specifically built with -O0 for various reasons. We previously tried enabling _FORTIFY_SOURCE (JDK-8032045) and ran into exactly this problem. See JDK-8047952 and JDK-8050803, which were addressed by backing out the use of _FORTIFY_SOURCE.

The files in question add $(OPT_CFLAGS/NOOPT) to their file-specific OPT_CFLAGS. I think adding "-U_FORTIFY_SOURCE" to OPT_CFLAGS/NOOPT on affected platforms might be sufficient to address this problem.

Defining _FORTIFY_SOURCE=2 may be overly agressive, as the documentation for this feature says this may cause some valid code to fail.