Magnus pointed out that I mistakenly replaced fno-strict-aliasing with
-Wno-strict-aliasing. Reverted that change.
http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/
/Erik
On 2016-02-05 10:05, Erik Joelsson wrote:
A while back, Magnus did a tremendous job of disabling most warnings
in the JDK native libraries and enabling warnings as errors on most of
them. However, some libraries, typically awt related, proved to be
harder.
One of the reasons was that some toolchains had different warning
labels specified for C vs C++ and would not accept the other kind
without printing new warning. For libraries containing both C and C++
source files, this prevented us from disabling all warnings. This
limitation in SetupNativeCompilation has since been fixed so I could
use that functionality to disable most remaining warnings.
Another reason is that some source files contain warnings that are
deemed severe enough by the compiler that they can't be individually
ignored. Since the team owning that source seem unwilling to fix these
warnings anyway, I have simply disabled all warnings on those specific
files, for the specific toolchains where it applies. I have tried to
add descriptive comments explaining each such occurrence.
I have tested this by building a full hotspot job and an openjdk only
job in JPRT. It is possible that people building with other toolchain
versions than Oracle will start seeing new build failures because of
more warnings in these libraries. In that case, either
--disable-warnings-as-errors, submit fixes for the warnings, or add
more warning ignores.
Bug: https://bugs.openjdk.java.net/browse/JDK-8148629
Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/
/Erik