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

Reply via email to