RFR: JDK-8075176 DISABLED_WARNINGS caused C++ compiler flags to get lost

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Tue Mar 17 12:58:32 UTC 2015


It turned out that the fix for JDK-8074796 (Disabling warnings on clang 
triggers compiler bug for libunpack) did not address the core issue.

In fact, there was no compiler bug in clang. (Surprise! :-)) Instead, 
what happened was that the makefile changes that turned on the warning 
flags, also affected other flags sent to the compiler. This happened on 
all toolchains, but was first noticed only for clang builds.

More precisely, due to the convoluted logic in SetupNativeCompilation, 
the value of "CFLAGS_release := -DPRODUCT" which was set in libunpack 
should have been copied by default to CXXFLAGS_release, so it could be 
used when compiling C++ code. However, if there are additional CXX flags 
set, then this copy does not happen. Due to the exact placement of the 
DISABLED_WARINGS flags code in SetupNativeCompilation, the CXX flags 
turned out to be non-empty when the "if CXX flags not set, then copy C 
flags by default" was executed. Hence, CFLAGS_release was not 
transferred to CXXFLAGS_release, and -DPRODUCT was lost when compiling 
the C++ files.

One could certainly argue that our entire handling of C flags vs C++ 
flags is not ideal. Hopefully, we can address that in the future, and 
create a more robust model.

For now, moving the code in SetupNativeCompilation will solve the 
problems which was introduced with the new warning option. This will 
also allow us to re-enable the warning statement for clang.

Bug: https://bugs.openjdk.java.net/browse/JDK-8075176
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8075176-disabled-warnings-removed-extra-cflags/webrev.01

/Magnus



More information about the build-dev mailing list