Re: gcc 7.3.1 build - warnings as errors in harfbuzz
Hi Matthias,
I've looked a little at this error and it is quite strange. First of
all, I can't reproduce it with a default gcc 7.3.0 and there doesn't
exist an official version of gcc 7.3.1 (at least I couldn't find it).
Also, I can't see the real error in the objected code. The values the
warning prints ("assuming directive output of 2147488582 bytes" and
"output 2 or more bytes (assuming 2147488583) into a destination of
size 127") seem to be excessively large. Every other reference for
this warning I could google reports much small numbers and I don't see
how a double could potentially use 2147488583 characters in the output
buffer.
Could this be a problem with the compiler you've used? Could you also
ask the people who compiled and patched it?
I did found the GCC bug "[7 Regression] -Wformat-overflow false
positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c" [1]
which seem to resemble to the output you see, but that should have
been fixed already in the 7.0 release.
Regards,
Volker
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79275
On Wed, Oct 10, 2018 at 3:14 PM Baesken, Matthias
wrote:
>
> Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or
> also on linux ppc64) I run into this build error :
>
>
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:
> In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned
> int)':
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
> error: '%g' directive output between 1 and 18446744073709551615 bytes may
> cause result to exceed 'INT_MAX' [-Werror=format-truncation=]
>len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g",
> variation->value));
>
> ~^
> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27:
> note: assuming directive output of 2147488582 bytes
> cc1plus: all warnings being treated as errors
>
> (build is a product - build)
>
> Setting –disable-warnings-as-errors works as a workaround , but of course
> this is not really what we want to do .
>
> Fixing in theharfbuzz sources in OpenJDk might be also not so nice
> because it would clash with imports of new versions of harfbuzz .
> Do you think we could disable the specific warning for the library
> compilation ?
>
> Any other great suggestions ?
>
>
> Thanks, Matthias
Re: gcc 7.3.1 build - warnings as errors in harfbuzz
GCC (since some version older than we support now) ignores disabling of unknown warning labels. This is a feature we depend on for these constructs. Without that it wouldn't be possible to list all the labels like this. (We used to check for this feature in GCC in configure and only use the warning disabling flags if GCC properly ignored unknowns, but since we require a newer version than that now, we no longer need to) /Erik On 2018-10-10 09:10, Baesken, Matthias wrote: Thanks. I am a bit worried that DISABLED_WARNINGS_gcc := format-truncation DISABLED_WARNINGS_CXX_gcc := format-truncation Could bring errors on older gcc versions , any ideas about this ? (will test with gcc 4.8 of course as well ) Best regards, Matthias -Original Message- From: Erik Joelsson Sent: Mittwoch, 10. Oktober 2018 18:08 To: Baesken, Matthias ; 'build- d...@openjdk.java.net' Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz I think that's fine. This is the granularity we have. /Erik On 2018-10-10 09:02, Baesken, Matthias wrote: Hi Erik, so I think I could disable the warning here : Awt2dLibraries.gmk - $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ NAME := fontmanager, \ WARNINGS_AS_ERRORS_xlc := false, \ DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to- pointer-cast \ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete- non-virtual-dtor strict-overflow \ maybe-uninitialized, \ ... (add format-truncationfor gcc in the warning-disabling section). However this would disable it also for other versions of gcc where the issue never showed up . Do you think this is fine (and safe for older gcc) ? Best regards, Matthias -Original Message- From: Erik Joelsson Sent: Mittwoch, 10. Oktober 2018 17:33 To: Baesken, Matthias ; 'build- d...@openjdk.java.net' Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz In this case, disabling the warning seems like the right thing to do. /Erik On 2018-10-10 06:14, Baesken, Matthias wrote: Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or also on linux ppc64) I run into this build error : /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [- Werror=format-truncation=] len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation- value)); ~^ /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes cc1plus: all warnings being treated as errors (build is a product - build) Setting –disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . Fixing in theharfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . Do you think we could disable the specific warning for the library compilation ? Any other great suggestions 😉 ? Thanks, Matthias
RE: gcc 7.3.1 build - warnings as errors in harfbuzz
Thanks. I am a bit worried that DISABLED_WARNINGS_gcc := format-truncation DISABLED_WARNINGS_CXX_gcc := format-truncation Could bring errors on older gcc versions , any ideas about this ? (will test with gcc 4.8 of course as well ) Best regards, Matthias > -Original Message- > From: Erik Joelsson > Sent: Mittwoch, 10. Oktober 2018 18:08 > To: Baesken, Matthias ; 'build- > d...@openjdk.java.net' > Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > > I think that's fine. This is the granularity we have. > > /Erik > > > On 2018-10-10 09:02, Baesken, Matthias wrote: > > Hi Erik, so I think I could disable the warning here : > > > > > > Awt2dLibraries.gmk > > - > > > > $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ > > NAME := fontmanager, \ > > > > WARNINGS_AS_ERRORS_xlc := false, \ > > DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to- > pointer-cast \ > > type-limits missing-field-initializers implicit-fallthrough \ > > strict-aliasing undef unused-function, \ > > DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete- > non-virtual-dtor strict-overflow \ > > maybe-uninitialized, \ > > ... > > > > (add format-truncationfor gcc in the warning-disabling section). > > However this would disable it also for other versions of gcc where the > issue never showed up . > > > > Do you think this is fine (and safe for older gcc) ? > > > > > > Best regards, Matthias > > > >> -Original Message- > >> From: Erik Joelsson > >> Sent: Mittwoch, 10. Oktober 2018 17:33 > >> To: Baesken, Matthias ; 'build- > >> d...@openjdk.java.net' > >> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > >> > >> In this case, disabling the warning seems like the right thing to do. > >> > >> /Erik > >> > >> > >> On 2018-10-10 06:14, Baesken, Matthias wrote: > >>> Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 > >>> (or also > >> on linux ppc64) I run into this build error : > >>> > >>> > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc: In function 'void > >> hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between > 1 > >> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' > [- > >> Werror=format-truncation=] > >>> len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", > variation- > >>> value)); > >>> > >> > ~^ > >> > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of > >> 2147488582 bytes > >>> cc1plus: all warnings being treated as errors > >>> > >>> (build is a product - build) > >>> > >>> Setting –disable-warnings-as-errors works as a workaround , but of > >> course this is not really what we want to do . > >>> Fixing in theharfbuzz sources in OpenJDk might be also not so > >>> nice > >> because it would clash with imports of new versions of harfbuzz . > >>> Do you think we could disable the specific warning for the library > >> compilation ? > >>> Any other great suggestions 😉 ? > >>> > >>> > >>> Thanks, Matthias
Re: gcc 7.3.1 build - warnings as errors in harfbuzz
I think that's fine. This is the granularity we have. /Erik On 2018-10-10 09:02, Baesken, Matthias wrote: Hi Erik, so I think I could disable the warning here : Awt2dLibraries.gmk - $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ NAME := fontmanager, \ WARNINGS_AS_ERRORS_xlc := false, \ DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-pointer-cast \ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete-non-virtual-dtor strict-overflow \ maybe-uninitialized, \ ... (add format-truncationfor gcc in the warning-disabling section). However this would disable it also for other versions of gcc where the issue never showed up . Do you think this is fine (and safe for older gcc) ? Best regards, Matthias -Original Message- From: Erik Joelsson Sent: Mittwoch, 10. Oktober 2018 17:33 To: Baesken, Matthias ; 'build- d...@openjdk.java.net' Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz In this case, disabling the warning seems like the right thing to do. /Erik On 2018-10-10 06:14, Baesken, Matthias wrote: Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or also on linux ppc64) I run into this build error : /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [- Werror=format-truncation=] len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation- value)); ~^ /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes cc1plus: all warnings being treated as errors (build is a product - build) Setting –disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . Fixing in theharfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . Do you think we could disable the specific warning for the library compilation ? Any other great suggestions 😉 ? Thanks, Matthias
RE: gcc 7.3.1 build - warnings as errors in harfbuzz
Hi Erik, so I think I could disable the warning here : Awt2dLibraries.gmk - $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ NAME := fontmanager, \ WARNINGS_AS_ERRORS_xlc := false, \ DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-pointer-cast \ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete-non-virtual-dtor strict-overflow \ maybe-uninitialized, \ ... (add format-truncationfor gcc in the warning-disabling section). However this would disable it also for other versions of gcc where the issue never showed up . Do you think this is fine (and safe for older gcc) ? Best regards, Matthias > -Original Message- > From: Erik Joelsson > Sent: Mittwoch, 10. Oktober 2018 17:33 > To: Baesken, Matthias ; 'build- > d...@openjdk.java.net' > Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > > In this case, disabling the warning seems like the right thing to do. > > /Erik > > > On 2018-10-10 06:14, Baesken, Matthias wrote: > > Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or > > also > on linux ppc64) I run into this build error : > > > > > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc: In function 'void > hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 > and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [- > Werror=format-truncation=] > > len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", > > variation- > >value)); > > > ~^ > > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of > 2147488582 bytes > > cc1plus: all warnings being treated as errors > > > > (build is a product - build) > > > > Setting –disable-warnings-as-errors works as a workaround , but of > course this is not really what we want to do . > > > > Fixing in theharfbuzz sources in OpenJDk might be also not so nice > because it would clash with imports of new versions of harfbuzz . > > Do you think we could disable the specific warning for the library > compilation ? > > > > Any other great suggestions 😉 ? > > > > > > Thanks, Matthias
Re: gcc 7.3.1 build - warnings as errors in harfbuzz
In this case, disabling the warning seems like the right thing to do. /Erik On 2018-10-10 06:14, Baesken, Matthias wrote: Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or also on linux ppc64) I run into this build error : /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=] len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation->value)); ~^ /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes cc1plus: all warnings being treated as errors (build is a product - build) Setting –disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . Fixing in theharfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . Do you think we could disable the specific warning for the library compilation ? Any other great suggestions 😉 ? Thanks, Matthias
gcc 7.3.1 build - warnings as errors in harfbuzz
Hello , when compiling jdk/jdk with gcc 7.3.1on linux x86_64 (or also on linux ppc64) I run into this build error : /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=] len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation->value)); ~^ /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes cc1plus: all warnings being treated as errors (build is a product - build) Setting –disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . Fixing in theharfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . Do you think we could disable the specific warning for the library compilation ? Any other great suggestions 😉 ? Thanks, Matthias
Re: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9
Hello, The 9 was just me being sloppy and thinking 9.x, I'm actually using 9.2. These are all the warnings I found in JDK libraries. There are additional ones in other parts of the build which have been dealt with in separate issues. /Erik On 2018-02-06 12:54, Sergey Bylokhov wrote: Hi, Erik. Why XCode 9 was selected? It seems that 9.2 is the latest one. 9.2 produces some additional warnings even after this fix. On 05/02/2018 14:54, Erik Joelsson wrote: When building with Xcode 9, we get some warnings triggered in jdk libraries. This patch tries to fix them. See bug description for more details on each of them. In short the following things are addressed: In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's relevant. The source needs to compile against the headers that are present. This was touched on earlier in this thread: http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html and when going back, it's quite clear to me that the fix done there was incorrect. In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we can't modify the source file itself, so here I've added a wrapper for zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches what's available on the Macosx version we are building for. This type of override can be brittle but seems to work OK in this case. While doing this, I also refactored the handling of libz cflags and libs. They are better set and exported from configure to be globally available in the build. We also get warnings when linking static libraries. These are easily fixed by adding the -mmacosx-version-min= arguments on these command lines just like we do for linking shared libraries and executables. I solved this by setting ARFLAGS and actually use that variable. Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 /Erik
Re: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9
Hi, Erik. Why XCode 9 was selected? It seems that 9.2 is the latest one. 9.2 produces some additional warnings even after this fix. On 05/02/2018 14:54, Erik Joelsson wrote: When building with Xcode 9, we get some warnings triggered in jdk libraries. This patch tries to fix them. See bug description for more details on each of them. In short the following things are addressed: In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's relevant. The source needs to compile against the headers that are present. This was touched on earlier in this thread: http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html and when going back, it's quite clear to me that the fix done there was incorrect. In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we can't modify the source file itself, so here I've added a wrapper for zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches what's available on the Macosx version we are building for. This type of override can be brittle but seems to work OK in this case. While doing this, I also refactored the handling of libz cflags and libs. They are better set and exported from configure to be globally available in the build. We also get warnings when linking static libraries. These are easily fixed by adding the -mmacosx-version-min= arguments on these command lines just like we do for linking shared libraries and executables. I solved this by setting ARFLAGS and actually use that variable. Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 /Erik -- Best regards, Sergey.
Re: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9
On 2018-02-05 23:54, Erik Joelsson wrote: When building with Xcode 9, we get some warnings triggered in jdk libraries. This patch tries to fix them. See bug description for more details on each of them. In short the following things are addressed: In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's relevant. The source needs to compile against the headers that are present. This was touched on earlier in this thread: http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html and when going back, it's quite clear to me that the fix done there was incorrect. In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we can't modify the source file itself, so here I've added a wrapper for zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches what's available on the Macosx version we are building for. This type of override can be brittle but seems to work OK in this case. While doing this, I also refactored the handling of libz cflags and libs. They are better set and exported from configure to be globally available in the build. We also get warnings when linking static libraries. These are easily fixed by adding the -mmacosx-version-min= arguments on these command lines just like we do for linking shared libraries and executables. I solved this by setting ARFLAGS and actually use that variable. Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Looks good to me. Thanks for the ZLIB cleanup. The naming and usage there has really been off. /Magnus Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 /Erik
Re: RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9
Erik: Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 Looks good. /Tim
RFR: JDK-8196803: Fix build warnings in jdk libraries with Xcode 9
When building with Xcode 9, we get some warnings triggered in jdk libraries. This patch tries to fix them. See bug description for more details on each of them. In short the following things are addressed: In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's relevant. The source needs to compile against the headers that are present. This was touched on earlier in this thread: http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html and when going back, it's quite clear to me that the fix done there was incorrect. In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we can't modify the source file itself, so here I've added a wrapper for zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches what's available on the Macosx version we are building for. This type of override can be brittle but seems to work OK in this case. While doing this, I also refactored the handling of libz cflags and libs. They are better set and exported from configure to be globally available in the build. We also get warnings when linking static libraries. These are easily fixed by adding the -mmacosx-version-min= arguments on these command lines just like we do for linking shared libraries and executables. I solved this by setting ARFLAGS and actually use that variable. Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8196803 /Erik
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
On 2016-08-25 23:28, Kim Barrett wrote: On Aug 24, 2016, at 5:48 AM, Erik Joelsson wrote: Hello, On 2016-08-23 18:12, Phil Race wrote: On 08/23/2016 08:47 AM, Erik Joelsson wrote: Hello, I do agree that maintaining the list of disabled warnings will be impossible unless we have a structured way of tracking for which compiler versions we disable what. Ideally we should be able to easily add conditions for when certain warnings should be disabled. We are unfortunately lacking that today and at least I don't have the bandwidth to fix that anytime soon. The official compilers are only really official for Oracle. The OpenJDK can (and should) be buildable with a much wider range of compiler versions. I agree there. This is fortunately not an "unbuildable" situation. The only other option I can think of which may or may not be palatable is to explicitly check the compiler version and add that disabled warning only for that exact compiler version. There'd still be some maintenance as that compiler version became either official .. or obsolete .. Is there precedent (or any kind of support) for that ? What I had in mind was a structured way of adding conditionals for some kind of ranges of compiler versions, or at least something like 6.*, or "greater than 4.9.3". It's pretty simple today to check for exact compiler versions but then we end up with a lot of changes when minor versions are bumped. I don't think that would be worth it. In this particular case is shift-negative-value a new warning in GCC 6? If that's the case it doesn't actually hurt adding it since GCC is nice enough to not complain about unknown warning tags. Not reviewing, but this caught my eye. The feature of not complaining about unknown -Wno-xxx warning options is only since gcc4.4. Some folks (like SAP) are still using versions that are older than that. That is true, so configure checks if gcc complains about unknown warnings. If not, we automatically do not add the -Wno-* arguments. /Erik If we do, just make sure to specify in a comment that it's specific to GCC version 6+.
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
On 8/24/16, 2:48 AM, Erik Joelsson wrote:
> Hello,
>
>
> On 2016-08-23 18:12, Phil Race wrote:
>> On 08/23/2016 08:47 AM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> I do agree that maintaining the list of disabled warnings will be
>>> impossible unless we have a structured way of tracking for which
>>> compiler versions we disable what. Ideally we should be able to easily
>>> add conditions for when certain warnings should be disabled. We are
>>> unfortunately lacking that today and at least I don't have the
>>> bandwidth to fix that anytime soon.
>>>
>>> The official compilers are only really official for Oracle. The
>>> OpenJDK can (and should) be buildable with a much wider range of
>>> compiler versions.
>> I agree there. This is fortunately not an "unbuildable" situation.
>> The only other option I can think of which may or may not be palatable
>> is to explicitly
>> check the compiler version and add that disabled warning only for that
>> exact compiler version.
>> There'd still be some maintenance as that compiler version became either
>> official .. or obsolete ..
>>
>> Is there precedent (or any kind of support) for that ?
> What I had in mind was a structured way of adding conditionals for
> some kind of ranges of compiler versions, or at least something like
> 6.*, or "greater than 4.9.3". It's pretty simple today to check for
> exact compiler versions but then we end up with a lot of changes when
> minor versions are bumped. I don't think that would be worth it.
>
> In this particular case is shift-negative-value a new warning in GCC
> 6? If that's the case it doesn't actually hurt adding it since GCC is
> nice enough to not complain about unknown warning tags. If we do, just
> make sure to specify in a comment that it's specific to GCC version 6+.
OK lets allow this with a comment and hope it does not set a trend.
I'd be largely unwilling to do it if it were not for the fact that someday
I presume we'll be using gcc6 ...
If there is a chance that - someday - you will get around to that
"structured way", maybe a comment could be added that follow a
standard format we devise so if this is requested for some other
compiler you are able to grep and find all the ones to fix.
Although this one makefile is probably the place to look so may
be it is not really needed.
The comment also ought to be phrased in a way that it is
apparent the disabled warning should be left alone.
-phil.
>
> /Erik
>> -phil.
>>
>>> Luckily we have the workaround of setting --disable-warnings-as-errors
>>> when this situation occurs.
>>>
>>> For reference, the compilers Oracle uses are listed in
>>> README-builds.md in the top level directory in the forest.
>>>
>>> So for now at least, I think Phil is right.
>>>
>>> /Erik
>>>
>>> On 2016-08-23 17:11, Philip Race wrote:
Erik .. please chime in if you disagree with the following
The goal here is to have no warnings with the *official* compilers.
If you are using something else and get warnings then either fix
the *source* or else you need to use --disable-warning-as-errors.
Otherwise we'll be suppressing the warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official*
compilers.
In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers
object
.. I am sure that official list is documented somewhere.
-phil.
On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I've fixed several warnings when we build OpenJDK with GCC 6 in
> JDK-8160294.
> However, I encountered shift-negative-value warnings at jdhuff.c
> on my
> Fedora 24 (GCC 6.1.1):
> --
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
>
>
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
>
>
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
>
>
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> :
> --
>
> I think these warnings are available from JDK-8074827.
> This issue enables warnings to fix in the source code.
> However, in review of JDK-8160294, I heared that warnings in IJG JPEG
> libr
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
On 8/24/16, 5:31 AM, Yasumasa Suenaga wrote: > Hi Erik, Phil, > > Thank you for replying. > I understand background of JDK-8074827. > >> In this particular case is shift-negative-value a new warning in GCC 6? > > Yes, this feature is implemented GCC 6: > https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/ I see. I tracked down the commit so yes, this seems to be the case. > > BTW, why is libjavajpeg only enabled these warnings? > For example, liblcms is disabled format-nonliteral, type-limits, and > misleading-indentation. We only disable the warnings that are observed .. not all warnings else we might as well turn off warnings completely. > > I agree compiler warnings is very useful to fix. However, I think a > part of source of libjavajpeg is third-party (developed by Independent > JPEG Group). > According to [1], warnings in this library should be suppressed. Yes. FWIW this is the most stable 3rd party library we have - by a long way - so it *could* be argued that tweaking it isn't likely to get lost any time soon but I'd still prefer to keep the source as it came. > > If all binaries which are included in JDK/JRE should be enabled all > compiler warnings, I think LCMS and any other libraries should be fixed. Well you would *have* to get upstream to resolve it. But it is whack-a-mole. As you have discovered new compilers generate new warnings .. and it is not monotonic either. -phil. > > Which policy is correct? > > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004495.html > > > On 2016/08/24 18:48, Erik Joelsson wrote: >> Hello, >> >> >> On 2016-08-23 18:12, Phil Race wrote: >>> On 08/23/2016 08:47 AM, Erik Joelsson wrote: Hello, I do agree that maintaining the list of disabled warnings will be impossible unless we have a structured way of tracking for which compiler versions we disable what. Ideally we should be able to easily add conditions for when certain warnings should be disabled. We are unfortunately lacking that today and at least I don't have the bandwidth to fix that anytime soon. The official compilers are only really official for Oracle. The OpenJDK can (and should) be buildable with a much wider range of compiler versions. >>> I agree there. This is fortunately not an "unbuildable" situation. >>> The only other option I can think of which may or may not be palatable >>> is to explicitly >>> check the compiler version and add that disabled warning only for that >>> exact compiler version. >>> There'd still be some maintenance as that compiler version became >>> either >>> official .. or obsolete .. >>> >>> Is there precedent (or any kind of support) for that ? >> What I had in mind was a structured way of adding conditionals for >> some kind of ranges of compiler versions, or at least something like >> 6.*, or "greater than 4.9.3". It's pretty simple today to check for >> exact compiler versions but then we end up with a lot of changes when >> minor versions are bumped. I don't think that would be worth it. >> >> In this particular case is shift-negative-value a new warning in GCC >> 6? If that's the case it doesn't actually hurt adding it since GCC is >> nice enough to not complain about unknown warning tags. If we do, >> just make sure to specify in a comment that it's specific to GCC >> version 6+. >> >> /Erik >>> -phil. >>> Luckily we have the workaround of setting --disable-warnings-as-errors when this situation occurs. For reference, the compilers Oracle uses are listed in README-builds.md in the top level directory in the forest. So for now at least, I think Phil is right. /Erik On 2016-08-23 17:11, Philip Race wrote: > Erik .. please chime in if you disagree with the following > The goal here is to have no warnings with the *official* compilers. > If you are using something else and get warnings then either fix > the *source* or else you need to use --disable-warning-as-errors. > > Otherwise we'll be suppressing the warnings for a whole range > of compilers and no one will know what the set is and these > bugs will become 'unfixable' and a continual chore of churn. > It will be something we should address as we move *official* > compilers. > > In fact the warning you want to suppress is one I just got rid of > (the > suppression) > http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2 > I don't think we want to add it back unless the *official* compilers > object > .. I am sure that official list is documented somewhere. > > -phil. > > > On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> I've fixed several warnings when we build OpenJDK with GCC 6 in >> JDK-8160294. >> However, I encountered shift-negative-value warnings at jdhuff.c >> on my >> F
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
> On Aug 24, 2016, at 5:48 AM, Erik Joelsson wrote: > > Hello, > > > On 2016-08-23 18:12, Phil Race wrote: >> On 08/23/2016 08:47 AM, Erik Joelsson wrote: >>> Hello, >>> >>> I do agree that maintaining the list of disabled warnings will be >>> impossible unless we have a structured way of tracking for which >>> compiler versions we disable what. Ideally we should be able to easily >>> add conditions for when certain warnings should be disabled. We are >>> unfortunately lacking that today and at least I don't have the >>> bandwidth to fix that anytime soon. >>> >>> The official compilers are only really official for Oracle. The >>> OpenJDK can (and should) be buildable with a much wider range of >>> compiler versions. >> I agree there. This is fortunately not an "unbuildable" situation. >> The only other option I can think of which may or may not be palatable >> is to explicitly >> check the compiler version and add that disabled warning only for that >> exact compiler version. >> There'd still be some maintenance as that compiler version became either >> official .. or obsolete .. >> >> Is there precedent (or any kind of support) for that ? > What I had in mind was a structured way of adding conditionals for some kind > of ranges of compiler versions, or at least something like 6.*, or "greater > than 4.9.3". It's pretty simple today to check for exact compiler versions > but then we end up with a lot of changes when minor versions are bumped. I > don't think that would be worth it. > > In this particular case is shift-negative-value a new warning in GCC 6? If > that's the case it doesn't actually hurt adding it since GCC is nice enough > to not complain about unknown warning tags. Not reviewing, but this caught my eye. The feature of not complaining about unknown -Wno-xxx warning options is only since gcc4.4. Some folks (like SAP) are still using versions that are older than that. > If we do, just make sure to specify in a comment that it's specific to GCC > version 6+.
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
Hi Erik, Phil,
Thank you for replying.
I understand background of JDK-8074827.
In this particular case is shift-negative-value a new warning in GCC 6?
Yes, this feature is implemented GCC 6:
https://gnu.wildebeest.org/blog/mjw/2016/02/15/looking-forward-to-gcc6-many-new-warnings/
BTW, why is libjavajpeg only enabled these warnings?
For example, liblcms is disabled format-nonliteral, type-limits, and
misleading-indentation.
I agree compiler warnings is very useful to fix. However, I think a part of
source of libjavajpeg is third-party (developed by Independent JPEG Group).
According to [1], warnings in this library should be suppressed.
If all binaries which are included in JDK/JRE should be enabled all compiler
warnings, I think LCMS and any other libraries should be fixed.
Which policy is correct?
Thanks,
Yasumasa
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004495.html
On 2016/08/24 18:48, Erik Joelsson wrote:
Hello,
On 2016-08-23 18:12, Phil Race wrote:
On 08/23/2016 08:47 AM, Erik Joelsson wrote:
Hello,
I do agree that maintaining the list of disabled warnings will be
impossible unless we have a structured way of tracking for which
compiler versions we disable what. Ideally we should be able to easily
add conditions for when certain warnings should be disabled. We are
unfortunately lacking that today and at least I don't have the
bandwidth to fix that anytime soon.
The official compilers are only really official for Oracle. The
OpenJDK can (and should) be buildable with a much wider range of
compiler versions.
I agree there. This is fortunately not an "unbuildable" situation.
The only other option I can think of which may or may not be palatable
is to explicitly
check the compiler version and add that disabled warning only for that
exact compiler version.
There'd still be some maintenance as that compiler version became either
official .. or obsolete ..
Is there precedent (or any kind of support) for that ?
What I had in mind was a structured way of adding conditionals for some kind of ranges of
compiler versions, or at least something like 6.*, or "greater than 4.9.3".
It's pretty simple today to check for exact compiler versions but then we end up with a
lot of changes when minor versions are bumped. I don't think that would be worth it.
In this particular case is shift-negative-value a new warning in GCC 6? If
that's the case it doesn't actually hurt adding it since GCC is nice enough to
not complain about unknown warning tags. If we do, just make sure to specify in
a comment that it's specific to GCC version 6+.
/Erik
-phil.
Luckily we have the workaround of setting --disable-warnings-as-errors
when this situation occurs.
For reference, the compilers Oracle uses are listed in
README-builds.md in the top level directory in the forest.
So for now at least, I think Phil is right.
/Erik
On 2016-08-23 17:11, Philip Race wrote:
Erik .. please chime in if you disagree with the following
The goal here is to have no warnings with the *official* compilers.
If you are using something else and get warnings then either fix
the *source* or else you need to use --disable-warning-as-errors.
Otherwise we'll be suppressing the warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official* compilers.
In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers
object
.. I am sure that official list is documented somewhere.
-phil.
On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
Hi all,
I've fixed several warnings when we build OpenJDK with GCC 6 in
JDK-8160294.
However, I encountered shift-negative-value warnings at jdhuff.c on my
Fedora 24 (GCC 6.1.1):
--
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
:
--
I think these warnings are available from JDK-8074827.
This issue enables warnings to fix in the source code.
However, in review of JDK-8160294, I heared that warnings in IJG JPEG
library should just be suppressed:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
So I think they should be suppressed and w
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
Hello,
On 2016-08-23 18:12, Phil Race wrote:
On 08/23/2016 08:47 AM, Erik Joelsson wrote:
Hello,
I do agree that maintaining the list of disabled warnings will be
impossible unless we have a structured way of tracking for which
compiler versions we disable what. Ideally we should be able to easily
add conditions for when certain warnings should be disabled. We are
unfortunately lacking that today and at least I don't have the
bandwidth to fix that anytime soon.
The official compilers are only really official for Oracle. The
OpenJDK can (and should) be buildable with a much wider range of
compiler versions.
I agree there. This is fortunately not an "unbuildable" situation.
The only other option I can think of which may or may not be palatable
is to explicitly
check the compiler version and add that disabled warning only for that
exact compiler version.
There'd still be some maintenance as that compiler version became either
official .. or obsolete ..
Is there precedent (or any kind of support) for that ?
What I had in mind was a structured way of adding conditionals for some
kind of ranges of compiler versions, or at least something like 6.*, or
"greater than 4.9.3". It's pretty simple today to check for exact
compiler versions but then we end up with a lot of changes when minor
versions are bumped. I don't think that would be worth it.
In this particular case is shift-negative-value a new warning in GCC 6?
If that's the case it doesn't actually hurt adding it since GCC is nice
enough to not complain about unknown warning tags. If we do, just make
sure to specify in a comment that it's specific to GCC version 6+.
/Erik
-phil.
Luckily we have the workaround of setting --disable-warnings-as-errors
when this situation occurs.
For reference, the compilers Oracle uses are listed in
README-builds.md in the top level directory in the forest.
So for now at least, I think Phil is right.
/Erik
On 2016-08-23 17:11, Philip Race wrote:
Erik .. please chime in if you disagree with the following
The goal here is to have no warnings with the *official* compilers.
If you are using something else and get warnings then either fix
the *source* or else you need to use --disable-warning-as-errors.
Otherwise we'll be suppressing the warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official* compilers.
In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers
object
.. I am sure that official list is documented somewhere.
-phil.
On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
Hi all,
I've fixed several warnings when we build OpenJDK with GCC 6 in
JDK-8160294.
However, I encountered shift-negative-value warnings at jdhuff.c on my
Fedora 24 (GCC 6.1.1):
--
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
:
--
I think these warnings are available from JDK-8074827.
This issue enables warnings to fix in the source code.
However, in review of JDK-8160294, I heared that warnings in IJG JPEG
library should just be suppressed:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
So I think they should be suppressed and we should fix as below:
--
diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
+++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
@@ -490,7 +490,7 @@
CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
$(LIBJAVA_HEADER_FLAGS) \
-I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
- DISABLED_WARNINGS_gcc := clobbered, \
+ DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
LDFLAGS := $(LDFLAGS_JDKLIB) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
--
If it is correct, I file it to JBS and upload webrev.
Do you think about it?
Thanks,
Yasumasa
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
On 08/23/2016 08:47 AM, Erik Joelsson wrote:
> Hello,
>
> I do agree that maintaining the list of disabled warnings will be
> impossible unless we have a structured way of tracking for which
> compiler versions we disable what. Ideally we should be able to easily
> add conditions for when certain warnings should be disabled. We are
> unfortunately lacking that today and at least I don't have the
> bandwidth to fix that anytime soon.
>
> The official compilers are only really official for Oracle. The
> OpenJDK can (and should) be buildable with a much wider range of
> compiler versions.
I agree there. This is fortunately not an "unbuildable" situation.
The only other option I can think of which may or may not be palatable
is to explicitly
check the compiler version and add that disabled warning only for that
exact compiler version.
There'd still be some maintenance as that compiler version became either
official .. or obsolete ..
Is there precedent (or any kind of support) for that ?
-phil.
> Luckily we have the workaround of setting --disable-warnings-as-errors
> when this situation occurs.
>
> For reference, the compilers Oracle uses are listed in
> README-builds.md in the top level directory in the forest.
>
> So for now at least, I think Phil is right.
>
> /Erik
>
> On 2016-08-23 17:11, Philip Race wrote:
>> Erik .. please chime in if you disagree with the following
>> The goal here is to have no warnings with the *official* compilers.
>> If you are using something else and get warnings then either fix
>> the *source* or else you need to use --disable-warning-as-errors.
>>
>> Otherwise we'll be suppressing the warnings for a whole range
>> of compilers and no one will know what the set is and these
>> bugs will become 'unfixable' and a continual chore of churn.
>> It will be something we should address as we move *official* compilers.
>>
>> In fact the warning you want to suppress is one I just got rid of (the
>> suppression)
>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
>> I don't think we want to add it back unless the *official* compilers
>> object
>> .. I am sure that official list is documented somewhere.
>>
>> -phil.
>>
>>
>> On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I've fixed several warnings when we build OpenJDK with GCC 6 in
>>> JDK-8160294.
>>> However, I encountered shift-negative-value warnings at jdhuff.c on my
>>> Fedora 24 (GCC 6.1.1):
>>> --
>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
>>>
>>> warning: left shift of negative value [-Wshift-negative-value]
>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
>>> ^~
>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
>>>
>>> warning: left shift of negative value [-Wshift-negative-value]
>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
>>> ^~
>>> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
>>>
>>> warning: left shift of negative value [-Wshift-negative-value]
>>> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
>>> :
>>> --
>>>
>>> I think these warnings are available from JDK-8074827.
>>> This issue enables warnings to fix in the source code.
>>> However, in review of JDK-8160294, I heared that warnings in IJG JPEG
>>> library should just be suppressed:
>>>
>>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
>>>
>>>
>>> So I think they should be suppressed and we should fix as below:
>>> --
>>> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
>>> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
>>> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
>>> @@ -490,7 +490,7 @@
>>> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
>>> $(LIBJAVA_HEADER_FLAGS) \
>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
>>> - DISABLED_WARNINGS_gcc := clobbered, \
>>> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
>>> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
>>> LDFLAGS := $(LDFLAGS_JDKLIB) \
>>> $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> --
>>>
>>> If it is correct, I file it to JBS and upload webrev.
>>> Do you think about it?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
Hello,
I do agree that maintaining the list of disabled warnings will be
impossible unless we have a structured way of tracking for which
compiler versions we disable what. Ideally we should be able to easily
add conditions for when certain warnings should be disabled. We are
unfortunately lacking that today and at least I don't have the bandwidth
to fix that anytime soon.
The official compilers are only really official for Oracle. The OpenJDK
can (and should) be buildable with a much wider range of compiler
versions. Luckily we have the workaround of setting
--disable-warnings-as-errors when this situation occurs.
For reference, the compilers Oracle uses are listed in README-builds.md
in the top level directory in the forest.
So for now at least, I think Phil is right.
/Erik
On 2016-08-23 17:11, Philip Race wrote:
Erik .. please chime in if you disagree with the following
The goal here is to have no warnings with the *official* compilers.
If you are using something else and get warnings then either fix
the *source* or else you need to use --disable-warning-as-errors.
Otherwise we'll be suppressing the warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official* compilers.
In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers object
.. I am sure that official list is documented somewhere.
-phil.
On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
Hi all,
I've fixed several warnings when we build OpenJDK with GCC 6 in
JDK-8160294.
However, I encountered shift-negative-value warnings at jdhuff.c on my
Fedora 24 (GCC 6.1.1):
--
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
:
--
I think these warnings are available from JDK-8074827.
This issue enables warnings to fix in the source code.
However, in review of JDK-8160294, I heared that warnings in IJG JPEG
library should just be suppressed:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
So I think they should be suppressed and we should fix as below:
--
diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
+++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
@@ -490,7 +490,7 @@
CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
$(LIBJAVA_HEADER_FLAGS) \
-I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
- DISABLED_WARNINGS_gcc := clobbered, \
+ DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
LDFLAGS := $(LDFLAGS_JDKLIB) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
--
If it is correct, I file it to JBS and upload webrev.
Do you think about it?
Thanks,
Yasumasa
Re: [OpenJDK 2D-Dev] [REGRESSION?] Build warnings at jdhuff.c with GCC 6
Erik .. please chime in if you disagree with the following
The goal here is to have no warnings with the *official* compilers.
If you are using something else and get warnings then either fix
the *source* or else you need to use --disable-warning-as-errors.
Otherwise we'll be suppressing the warnings for a whole range
of compilers and no one will know what the set is and these
bugs will become 'unfixable' and a continual chore of churn.
It will be something we should address as we move *official* compilers.
In fact the warning you want to suppress is one I just got rid of (the
suppression)
http://hg.openjdk.java.net/jdk9/client/jdk/rev/d4f7412a51d2
I don't think we want to add it back unless the *official* compilers object
.. I am sure that official list is documented somewhere.
-phil.
On 8/23/16, 6:10 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I've fixed several warnings when we build OpenJDK with GCC 6 in
> JDK-8160294.
> However, I encountered shift-negative-value warnings at jdhuff.c on my
> Fedora 24 (GCC 6.1.1):
> --
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> ^~
> /home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
> warning: left shift of negative value [-Wshift-negative-value]
> { 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
> :
> --
>
> I think these warnings are available from JDK-8074827.
> This issue enables warnings to fix in the source code.
> However, in review of JDK-8160294, I heared that warnings in IJG JPEG
> library should just be suppressed:
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
>
>
> So I think they should be suppressed and we should fix as below:
> --
> diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
> +++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
> @@ -490,7 +490,7 @@
> CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
> $(LIBJAVA_HEADER_FLAGS) \
> -I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
> - DISABLED_WARNINGS_gcc := clobbered, \
> + DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
> LDFLAGS := $(LDFLAGS_JDKLIB) \
> $(call SET_SHARED_LIBRARY_ORIGIN), \
> --
>
> If it is correct, I file it to JBS and upload webrev.
> Do you think about it?
>
>
> Thanks,
>
> Yasumasa
>
>
[REGRESSION?] Build warnings at jdhuff.c with GCC 6
Hi all,
I've fixed several warnings when we build OpenJDK with GCC 6 in JDK-8160294.
However, I encountered shift-negative-value warnings at jdhuff.c on my Fedora
24 (GCC 6.1.1):
--
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:13:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:28:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
^~
/home/ysuenaga/OpenJDK/hs/jdk/src/java.desktop/share/native/libjavajpeg/jdhuff.c:458:43:
warning: left shift of negative value [-Wshift-negative-value]
{ 0, ((-1)<<1) + 1, ((-1)<<2) + 1, ((-1)<<3) + 1, ((-1)<<4) + 1,
:
--
I think these warnings are available from JDK-8074827.
This issue enables warnings to fix in the source code.
However, in review of JDK-8160294, I heared that warnings in IJG JPEG library
should just be suppressed:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004497.html
So I think they should be suppressed and we should fix as below:
--
diff -r b548b8217d8c make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk Mon Aug 22 19:28:36 2016 -0700
+++ b/make/lib/Awt2dLibraries.gmk Tue Aug 23 22:08:44 2016 +0900
@@ -490,7 +490,7 @@
CFLAGS := $(CFLAGS_JDKLIB) $(BUILD_LIBJAVAJPEG_HEADERS) \
$(LIBJAVA_HEADER_FLAGS) \
-I$(SUPPORT_OUTPUTDIR)/headers/java.desktop, \
-DISABLED_WARNINGS_gcc := clobbered, \
+DISABLED_WARNINGS_gcc := clobbered shift-negative-value, \
MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libjpeg/mapfile-vers, \
LDFLAGS := $(LDFLAGS_JDKLIB) \
$(call SET_SHARED_LIBRARY_ORIGIN), \
--
If it is correct, I file it to JBS and upload webrev.
Do you think about it?
Thanks,
Yasumasa
Re: build warnings
Amen to that Magnus - what possible motive can there be to fix invisible, benign 'problems' ? -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 17:42, Kelly O'Hair wrote: > > On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie < > magnus.ihse.bur...@oracle.com> wrote: > > > On 2014-12-02 22:59, Jonathan Gibbons wrote: > >> Build folk, > >> > >> The build has always generated warnings (sigh!) but right now, the > warnings look scarier than usual. > >> > >> In particular, when the build terminates, I get a couple of screenfuls > of messages like this: > >> > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ‘SplashScreenThread’: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: > warning: ignoring return value of ‘pipe’, declared with attribute > warn_unused_result [-Wunused-result] > >> pipe(splash->controlpipe); > >> ^ > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: > In function ‘initFormat’: > >> > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: > warning: ‘numBits’ may be used uninitialized in this function > [-Wmaybe-uninitialized] > >> format->shift[i] = shift + numBits - i * 8 - 8; > >> ^ > >> > >> What would it take to have some sort of campaign to reduce build > warnings like these? We've made good progress on lint and doclint warnings > for Java code and doc comments; what does it take to start on native code > warnings? > > > > Actually, I've already started on such a campain. ;-) > > > > I believe the way to go is: > > 1) disable all (or more or less all) of the current flood of warnings > > 2) open bugs for all disabled warnings on the corresponding components, > indicating that the owner of the component should: > > a) fix the issue with the source code and re-enable the warning, or > > b) come up with a good reason why the warning is bad/broken and should > be left disabled for that component. > > > > I have started on 1). I have a local forest which disables most of the > warnings for linux builds. I'm about to move on to the other platforms as > well, but other work came between. > > > > /Magnus > > Speaking from a bit of experience, if you disable the warnings, odds are > good that they will never get fixed because being disabled will be > considered by some as "we have no warnings" and they will work on other > things, like adding more code with more invisible disabled warnings. > Granted some of the C/C++ compiler warnings are very dubious and of little > value, but many are not. Disabling the less valuable warnings makes sense, > but I would caution on disabling all warnings. Just my 2 cents... > > -kto > > >
Re: build warnings
On Dec 3, 2014, at 3:09 AM, Magnus Ihse Bursie wrote: > On 2014-12-02 22:59, Jonathan Gibbons wrote: >> Build folk, >> >> The build has always generated warnings (sigh!) but right now, the warnings >> look scarier than usual. >> >> In particular, when the build terminates, I get a couple of screenfuls of >> messages like this: >> >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: >> In function ‘SplashScreenThread’: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: >> warning: ignoring return value of ‘pipe’, declared with attribute >> warn_unused_result [-Wunused-result] >> pipe(splash->controlpipe); >> ^ >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: >> In function ‘initFormat’: >> /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: >> warning: ‘numBits’ may be used uninitialized in this function >> [-Wmaybe-uninitialized] >> format->shift[i] = shift + numBits - i * 8 - 8; >> ^ >> >> What would it take to have some sort of campaign to reduce build warnings >> like these? We've made good progress on lint and doclint warnings for Java >> code and doc comments; what does it take to start on native code warnings? > > Actually, I've already started on such a campain. ;-) > > I believe the way to go is: > 1) disable all (or more or less all) of the current flood of warnings > 2) open bugs for all disabled warnings on the corresponding components, > indicating that the owner of the component should: > a) fix the issue with the source code and re-enable the warning, or > b) come up with a good reason why the warning is bad/broken and should be > left disabled for that component. > > I have started on 1). I have a local forest which disables most of the > warnings for linux builds. I'm about to move on to the other platforms as > well, but other work came between. > > /Magnus Speaking from a bit of experience, if you disable the warnings, odds are good that they will never get fixed because being disabled will be considered by some as "we have no warnings" and they will work on other things, like adding more code with more invisible disabled warnings. Granted some of the C/C++ compiler warnings are very dubious and of little value, but many are not. Disabling the less valuable warnings makes sense, but I would caution on disabling all warnings. Just my 2 cents... -kto
Re: build warnings
On 12/03/2014 03:09 AM, Magnus Ihse Bursie wrote: On 2014-12-02 22:59, Jonathan Gibbons wrote: Build folk, The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. In particular, when the build terminates, I get a couple of screenfuls of messages like this: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ‘SplashScreenThread’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ‘pipe’, declared with attribute warn_unused_result [-Wunused-result] pipe(splash->controlpipe); ^ /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ‘initFormat’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ‘numBits’ may be used uninitialized in this function [-Wmaybe-uninitialized] format->shift[i] = shift + numBits - i * 8 - 8; ^ What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? Actually, I've already started on such a campain. ;-) I believe the way to go is: 1) disable all (or more or less all) of the current flood of warnings 2) open bugs for all disabled warnings on the corresponding components, indicating that the owner of the component should: a) fix the issue with the source code and re-enable the warning, or b) come up with a good reason why the warning is bad/broken and should be left disabled for that component. I have started on 1). I have a local forest which disables most of the warnings for linux builds. I'm about to move on to the other platforms as well, but other work came between. /Magnus Magnus, Thank you for the update; it's great to hear this is being looked at. -- Jon
Re: build warnings
On 03/12/2014 07:58, Staffan Larsen wrote: These are warnings in the java.desktop module. I don’t know what the appropriate email list is for java.desktop discussions, but perhaps bringing it up there would be the right thing to do? Most of the warnings that I see are in the AWT and 2D code and so awt-dev and 2d-dev would be the mailing lists to bring patches for review. -Alan
Re: build warnings
On 2014-12-02 22:59, Jonathan Gibbons wrote: Build folk, The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. In particular, when the build terminates, I get a couple of screenfuls of messages like this: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ‘SplashScreenThread’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ‘pipe’, declared with attribute warn_unused_result [-Wunused-result] pipe(splash->controlpipe); ^ /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ‘initFormat’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ‘numBits’ may be used uninitialized in this function [-Wmaybe-uninitialized] format->shift[i] = shift + numBits - i * 8 - 8; ^ What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? Actually, I've already started on such a campain. ;-) I believe the way to go is: 1) disable all (or more or less all) of the current flood of warnings 2) open bugs for all disabled warnings on the corresponding components, indicating that the owner of the component should: a) fix the issue with the source code and re-enable the warning, or b) come up with a good reason why the warning is bad/broken and should be left disabled for that component. I have started on 1). I have a local forest which disables most of the warnings for linux builds. I'm about to move on to the other platforms as well, but other work came between. /Magnus
Re: build warnings
These are warnings in the java.desktop module. I don’t know what the appropriate email list is for java.desktop discussions, but perhaps bringing it up there would be the right thing to do? /Staffan > On 2 dec 2014, at 22:59, Jonathan Gibbons wrote: > > Build folk, > > The build has always generated warnings (sigh!) but right now, the warnings > look scarier than usual. > > In particular, when the build terminates, I get a couple of screenfuls of > messages like this: > > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: > In function ‘SplashScreenThread’: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: > warning: ignoring return value of ‘pipe’, declared with attribute > warn_unused_result [-Wunused-result] > pipe(splash->controlpipe); > ^ > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: > In function ‘initFormat’: > /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: > warning: ‘numBits’ may be used uninitialized in this function > [-Wmaybe-uninitialized] > format->shift[i] = shift + numBits - i * 8 - 8; > ^ > > What would it take to have some sort of campaign to reduce build warnings > like these? We've made good progress on lint and doclint warnings for Java > code and doc comments; what does it take to start on native code warnings? > > -- Jon
build warnings
Build folk, The build has always generated warnings (sigh!) but right now, the warnings look scarier than usual. In particular, when the build terminates, I get a couple of screenfuls of messages like this: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c: In function ‘SplashScreenThread’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c:742:9: warning: ignoring return value of ‘pipe’, declared with attribute warn_unused_result [-Wunused-result] pipe(splash->controlpipe); ^ /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c: In function ‘initFormat’: /w/jjg/work/jfm2.0/dev.8059977.sjfm/jdk/src/java.desktop/share/native/libsplashscreen/splashscreen_gfx_impl.c:305:34: warning: ‘numBits’ may be used uninitialized in this function [-Wmaybe-uninitialized] format->shift[i] = shift + numBits - i * 8 - 8; ^ What would it take to have some sort of campaign to reduce build warnings like these? We've made good progress on lint and doclint warnings for Java code and doc comments; what does it take to start on native code warnings? -- Jon
Re: build warnings
Great. I'll close the bug I filed as a dup of this one then. Thanks Michael On 10/02/14 10:39, Chris Hegarty wrote: On 08/02/14 00:41, Mike Duigou wrote: Part of the issue seems to be that the meaning of -Wno-unused seems to have changed and/or become ineffective. It's reported that it previously hid all unused parameter warnings though it doesn't seem to on any compiler I'm currently using. I've included -Wno-unused-parameter with the changes going in JDK-8030350 so you should soon see the number of these warnings greatly diminish. Thanks Mike, -Chris. Mike On Feb 7 2014, at 02:02 , Michael McMahon wrote: Just wondering is there a plan to deal with build warnings on Linux? I was experimenting with macros that could be used to deal with the -Wunused-parameter warning, but there are over 3700 occurrences and frankly it's not a very useful warning in the context of JNI formal function parameters at least. Some more useful warnings are getting lost in the noise. - Michael.
Re: build warnings
On 08/02/14 00:41, Mike Duigou wrote: Part of the issue seems to be that the meaning of -Wno-unused seems to have changed and/or become ineffective. It's reported that it previously hid all unused parameter warnings though it doesn't seem to on any compiler I'm currently using. I've included -Wno-unused-parameter with the changes going in JDK-8030350 so you should soon see the number of these warnings greatly diminish. Thanks Mike, -Chris. Mike On Feb 7 2014, at 02:02 , Michael McMahon wrote: Just wondering is there a plan to deal with build warnings on Linux? I was experimenting with macros that could be used to deal with the -Wunused-parameter warning, but there are over 3700 occurrences and frankly it's not a very useful warning in the context of JNI formal function parameters at least. Some more useful warnings are getting lost in the noise. - Michael.
Re: build warnings
Part of the issue seems to be that the meaning of -Wno-unused seems to have changed and/or become ineffective. It's reported that it previously hid all unused parameter warnings though it doesn't seem to on any compiler I'm currently using. I've included -Wno-unused-parameter with the changes going in JDK-8030350 so you should soon see the number of these warnings greatly diminish. Mike On Feb 7 2014, at 02:02 , Michael McMahon wrote: > Just wondering is there a plan to deal with build warnings on Linux? > > I was experimenting with macros that could be used to deal with the > -Wunused-parameter > warning, but there are over 3700 occurrences and frankly it's not a very > useful > warning in the context of JNI formal function parameters at least. Some more > useful > warnings are getting lost in the noise. > > - Michael. >
Re: build warnings
On 07/02/14 10:43, Michael McMahon wrote: It seems, the warning is emitted by the combination of: -W -Wall and could be disabled by adding -Wno-unused-parameter Given the definition of JNI method signatures, then I agree with this. It would be really helpful to be able to see "real" warnings. -Chris. Michael On 07/02/14 10:06, Dmitry Samersoff wrote: Michael, I'm totally agree with you (and had sent to build-dev approx the same letter about two weeks ago). On my opinion we should turn off unused parameter warning, at least for product build. -Dmitry On 2014-02-07 14:02, Michael McMahon wrote: Just wondering is there a plan to deal with build warnings on Linux? I was experimenting with macros that could be used to deal with the -Wunused-parameter warning, but there are over 3700 occurrences and frankly it's not a very useful warning in the context of JNI formal function parameters at least. Some more useful warnings are getting lost in the noise. - Michael.
Re: build warnings
It seems, the warning is emitted by the combination of: -W -Wall and could be disabled by adding -Wno-unused-parameter Michael On 07/02/14 10:06, Dmitry Samersoff wrote: Michael, I'm totally agree with you (and had sent to build-dev approx the same letter about two weeks ago). On my opinion we should turn off unused parameter warning, at least for product build. -Dmitry On 2014-02-07 14:02, Michael McMahon wrote: Just wondering is there a plan to deal with build warnings on Linux? I was experimenting with macros that could be used to deal with the -Wunused-parameter warning, but there are over 3700 occurrences and frankly it's not a very useful warning in the context of JNI formal function parameters at least. Some more useful warnings are getting lost in the noise. - Michael.
Re: build warnings
Michael, I'm totally agree with you (and had sent to build-dev approx the same letter about two weeks ago). On my opinion we should turn off unused parameter warning, at least for product build. -Dmitry On 2014-02-07 14:02, Michael McMahon wrote: > Just wondering is there a plan to deal with build warnings on Linux? > > I was experimenting with macros that could be used to deal with the > -Wunused-parameter > warning, but there are over 3700 occurrences and frankly it's not a very > useful > warning in the context of JNI formal function parameters at least. Some > more useful > warnings are getting lost in the noise. > > - Michael. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code.
build warnings
Just wondering is there a plan to deal with build warnings on Linux? I was experimenting with macros that could be used to deal with the -Wunused-parameter warning, but there are over 3700 occurrences and frankly it's not a very useful warning in the context of JNI formal function parameters at least. Some more useful warnings are getting lost in the noise. - Michael.
Re: RFE: Suggestion for build warnings
Here is a basic first draft of a script to remove the chatty fluff from a build log. I tried it on a build log from a linux box I use. The entire log is 1511 lines long; the reduced log is 584 lines long, meaning that 39% of the log is issues that maybe need addressing. -- Jon cat $1 | grep -v -E '^(Assembling|Compiling|Copying|Creating|Generating|Importing|Linking|Making|Running|Updating|Using|Verifying) ' | grep -v -E '^(Aliases|Cache|Classes|INFO): ' | grep -v -E '^All done.' | grep -v -E '^$' | grep -v -E '^(## |---*)' | grep -v -E '^(Start|End|[0-9][0-9]:[0-9][0-9]:[0-9][0-9]) ' On 04/25/2013 12:05 PM, Jonathan Gibbons wrote: Build folk, There are two types of line in a typical build.log file: there are "info" lines which detail the ongoing progress of the build, and there are "other" lines containing info which ought to be of interest to someone: warnings, errors, etc. Previously, attempts to clean up build issues have focussed on analyzing the log for warnings. This time, I'm going to suggest the opposite. How about providing a script somewhere which can be used after a build to filter out the "info" lines, leaving just the warnings and error messages, so that they can more easily be seen and addressed. The script could simply be a series of "grep -v" commands, filtering out lines beginning "Compiing " or "Assembling..." or "## comment" or "INFO: ..." or "Importing ..." etc. For those folk using Hudson to build OpenJDK on an ongoing basis, maybe the number of lines in this reduced log would be of interest, and could be tracked in a Hudson trend graph. -- Jon
RFE: Suggestion for build warnings
Build folk, There are two types of line in a typical build.log file: there are "info" lines which detail the ongoing progress of the build, and there are "other" lines containing info which ought to be of interest to someone: warnings, errors, etc. Previously, attempts to clean up build issues have focussed on analyzing the log for warnings. This time, I'm going to suggest the opposite. How about providing a script somewhere which can be used after a build to filter out the "info" lines, leaving just the warnings and error messages, so that they can more easily be seen and addressed. The script could simply be a series of "grep -v" commands, filtering out lines beginning "Compiing " or "Assembling..." or "## comment" or "INFO: ..." or "Importing ..." etc. For those folk using Hudson to build OpenJDK on an ongoing basis, maybe the number of lines in this reduced log would be of interest, and could be tracked in a Hudson trend graph. -- Jon
hg: jdk7/build/corba: 6733313: corba build warnings: /bin/sh: gcc: not found
Changeset: f1e1cccbd13a Author:ohair Date: 2009-05-19 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/f1e1cccbd13a 6733313: corba build warnings: /bin/sh: gcc: not found Reviewed-by: tbell ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-sun.gmk
Re: getting a handle on build warnings
With the integration of the changeset: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e093efae8c5f The jdk7 compiler warnings have gone down a bunch, running my script over the build logs of all platforms I came up with the following top 20: Top 20 'src/' files mentioned in warning messages: - 2062 src/closed/share/classes/sun/jdbc/odbc/JdbcOdbc.c 1096 src/solaris/native/sun/awt/gtk2_interface.c 883 src/closed/share/native/sun/java2d/cmm/kcms/evalth13.c 276 src/build/tools/javazic/Gen.java 272 src/closed/share/native/sun/java2d/cmm/kcms/evalth14.c 170 src/share/native/sun/security/jgss/wrapper/GSSLibStub.c 136 src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c 128 src/share/native/sun/font/layout/LEGlyphStorage.h 114 src/share/classes/javax/sql/rowset/BaseRowSet.java 96 src/solaris/native/java/io/io_util_md.h 92 src/solaris/native/sun/java2d/x11/X11Renderer.c 84 src/build/tools/javazic/Time.java 64 src/share/native/sun/awt/giflib/dgif_lib.c 62 src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32U16Func.c 62 src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32S16Func.c 58 src/closed/share/native/sun/font/t2k/t2k.c 52 src/share/native/sun/awt/image/jpeg/imageioJPEG.c 48 src/share/classes/java/util/Formatter.java 48 src/javaws/solaris/native/system_md.c 48 src/build/tools/compilefontconfig/CompileFontConfig.java I'll look at fixing JdbcOdbc.c. Slowly this WILL get clean this up. -kto Kelly O'Hair wrote: FYI... I dug up my old wstats ksh script and ran it over a concatenation of the latest jdk7 build 30 logs for all 8 of builds done by Java Release Engineering (solaris-i586, solaris-x64, solaris-sparc, solaris-sparcv9, linux-i586, linux-x64, windows-i586, and windows-x64). Granted, these are OLD Linux systems with gcc 3.2, and lots of duplicates here. The problems with dealing with the C/C++ warnings is that the different compilers and different releases of the compilers create a bit of an unknown when trying to fix warnings. Fixing a warning from gcc4 might just trigger a new warning for some other reason from the Sun Studio compiler, can be frustrating. And using just a slightly newer or patched gcc or Sun Studio compiler might generate new warnings you haven't seen before. This has gotten better over time but continues to be an issue. A danger also lies in how a warning is fixed in native code that needs to work on all platforms and with different compilers, for example, adding a cast like '(long)' might shut up a warning, but could break Windows X64 where a long is 32bits not 64bits. People need to be very careful in the native code. At least with the javac warnings, fixing them is more concrete, and probably less risky ;^) I'm all in favor of fixing the warnings, just trying to make sure it's done safely. ;^) -kto - Warning Message Counts: -- 15790 ld warnings (contains 'ld:') 6686 C warnings (contains '[.]c[":]') 1616 C Include file warnings (contains '[.]h[":]') 9700 C++ warnings (contains '[.]cpp[":]') 0 C++ Include file warnings (contains '[.]hpp[":]') 4432 Java warnings (contains '.java:' or 'Note:' ) 0 VM warnings (contains 'VM warning:' ) 600 Javadoc warnings (contains ': warning -') 250 Compiler driver warnings (contains cc: or CC: or 'cl :') 59 GNU make warnings (contains '.gmk:' or 'akefile:' or '(ignored)' or starts with 'gnumake') 276 Shell warnings (contains ': not found' or 'awk:') 187 Build warnings (contains WARNING:) 312 Font warnings (contains 'entry is missing') - 39908 Total of above warnings 29252 Messages that appear to be duplicates 18 Remaining errors not counted warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does
Re: getting a handle on build warnings
I understand. FYI... I filed a serviceability bug on those warnings, looks like we have some new ones that creeped in. I also pinged Dave Bristor on the warnings in the jar code, there was a bug on that already. I marked these bugs with the keyword "warnings", so I can find them easily. I'm loading up my guns and will do what I can to hunt down the warnings. ;^) -kto Jonathan Gibbons wrote: I agree that fixing warnings is not necessarily an easy task. My goal in writing the tool was to make it easy for people to scan the set of warnings, and say, "wow, that one looks really serious, I'd better fix that!" -- Jon Kelly O'Hair wrote: FYI... I dug up my old wstats ksh script and ran it over a concatenation of the latest jdk7 build 30 logs for all 8 of builds done by Java Release Engineering (solaris-i586, solaris-x64, solaris-sparc, solaris-sparcv9, linux-i586, linux-x64, windows-i586, and windows-x64). Granted, these are OLD Linux systems with gcc 3.2, and lots of duplicates here. The problems with dealing with the C/C++ warnings is that the different compilers and different releases of the compilers create a bit of an unknown when trying to fix warnings. Fixing a warning from gcc4 might just trigger a new warning for some other reason from the Sun Studio compiler, can be frustrating. And using just a slightly newer or patched gcc or Sun Studio compiler might generate new warnings you haven't seen before. This has gotten better over time but continues to be an issue. A danger also lies in how a warning is fixed in native code that needs to work on all platforms and with different compilers, for example, adding a cast like '(long)' might shut up a warning, but could break Windows X64 where a long is 32bits not 64bits. People need to be very careful in the native code. At least with the javac warnings, fixing them is more concrete, and probably less risky ;^) I'm all in favor of fixing the warnings, just trying to make sure it's done safely. ;^) -kto - Warning Message Counts: -- 15790 ld warnings (contains 'ld:') 6686 C warnings (contains '[.]c[":]') 1616 C Include file warnings (contains '[.]h[":]') 9700 C++ warnings (contains '[.]cpp[":]') 0 C++ Include file warnings (contains '[.]hpp[":]') 4432 Java warnings (contains '.java:' or 'Note:' ) 0 VM warnings (contains 'VM warning:' ) 600 Javadoc warnings (contains ': warning -') 250 Compiler driver warnings (contains cc: or CC: or 'cl :') 59 GNU make warnings (contains '.gmk:' or 'akefile:' or '(ignored)' or starts with 'gnumake') 276 Shell warnings (contains ': not found' or 'awk:') 187 Build warnings (contains WARNING:) 312 Font warnings (contains 'entry is missing') - 39908 Total of above warnings 29252 Messages that appear to be duplicates 18 Remaining errors not counted warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist Top 20 'src/' files mentioned in warning messages: - 7972 src/share/native/com/sun/java/util/jar/pack/coding.cpp 2062 src/closed/share/classes/sun/jdbc/odbc/JdbcOdbc.c 1278 src/share/native/com/sun/java/util/jar/pack/unpack.cpp 1188 src/share/classes/sun/corba/Bridge.java 1096 src/solaris/native/sun/awt/gtk2_interface.c 888 src/closed/share/native/sun/java2d/cmm/kcms/evalth13.c 720 src/share/native/com/sun/java/util/jar/pack/bands.h 276 src/share/native/com/sun/java/util/jar/pack/unpack.h 276 src/build/tools/javazic/Gen.java
Re: getting a handle on build warnings
I agree that fixing warnings is not necessarily an easy task. My goal in writing the tool was to make it easy for people to scan the set of warnings, and say, "wow, that one looks really serious, I'd better fix that!" -- Jon Kelly O'Hair wrote: FYI... I dug up my old wstats ksh script and ran it over a concatenation of the latest jdk7 build 30 logs for all 8 of builds done by Java Release Engineering (solaris-i586, solaris-x64, solaris-sparc, solaris-sparcv9, linux-i586, linux-x64, windows-i586, and windows-x64). Granted, these are OLD Linux systems with gcc 3.2, and lots of duplicates here. The problems with dealing with the C/C++ warnings is that the different compilers and different releases of the compilers create a bit of an unknown when trying to fix warnings. Fixing a warning from gcc4 might just trigger a new warning for some other reason from the Sun Studio compiler, can be frustrating. And using just a slightly newer or patched gcc or Sun Studio compiler might generate new warnings you haven't seen before. This has gotten better over time but continues to be an issue. A danger also lies in how a warning is fixed in native code that needs to work on all platforms and with different compilers, for example, adding a cast like '(long)' might shut up a warning, but could break Windows X64 where a long is 32bits not 64bits. People need to be very careful in the native code. At least with the javac warnings, fixing them is more concrete, and probably less risky ;^) I'm all in favor of fixing the warnings, just trying to make sure it's done safely. ;^) -kto - Warning Message Counts: -- 15790 ld warnings (contains 'ld:') 6686 C warnings (contains '[.]c[":]') 1616 C Include file warnings (contains '[.]h[":]') 9700 C++ warnings (contains '[.]cpp[":]') 0 C++ Include file warnings (contains '[.]hpp[":]') 4432 Java warnings (contains '.java:' or 'Note:' ) 0 VM warnings (contains 'VM warning:' ) 600 Javadoc warnings (contains ': warning -') 250 Compiler driver warnings (contains cc: or CC: or 'cl :') 59 GNU make warnings (contains '.gmk:' or 'akefile:' or '(ignored)' or starts with 'gnumake') 276 Shell warnings (contains ': not found' or 'awk:') 187 Build warnings (contains WARNING:) 312 Font warnings (contains 'entry is missing') - 39908 Total of above warnings 29252 Messages that appear to be duplicates 18 Remaining errors not counted warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist Top 20 'src/' files mentioned in warning messages: - 7972 src/share/native/com/sun/java/util/jar/pack/coding.cpp 2062 src/closed/share/classes/sun/jdbc/odbc/JdbcOdbc.c 1278 src/share/native/com/sun/java/util/jar/pack/unpack.cpp 1188 src/share/classes/sun/corba/Bridge.java 1096 src/solaris/native/sun/awt/gtk2_interface.c 888 src/closed/share/native/sun/java2d/cmm/kcms/evalth13.c 720 src/share/native/com/sun/java/util/jar/pack/bands.h 276 src/share/native/com/sun/java/util/jar/pack/unpack.h 276 src/build/tools/javazic/Gen.java 272 src/closed/share/native/sun/java2d/cmm/kcms/evalth14.c 252 src/share/classes/sun/nio/ch/FileChannelImpl.java 204 src/share/native/com/sun/java/util/jar/pack/bytes.h 204 src/share/classes/org/omg/CORBA/ORB.java 192 src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java 170 src/share/native/sun/security/jgss/wrapper/GSSLibStub.c 140 src/share/native/com/sun/java/util/jar/pack/zip.cpp 136
Re: getting a handle on build warnings
and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon JDK Build Warnings * Comparison against reference results o New warnings not found in reference files <#REF_DELTA_LOCNS> * Warnings categorized by location o Warning counts, sorted alphabetically by location <#LOCN_COUNTS_ALPHA> o Warning counts, sorted by frequency of location <#LOCN_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> * Warnings categorized by type o Warning counts, sorted alphabetically by type <#TYPE_COUNTS_ALPHA> o Warning counts, sorted by frequency of type <#TYPE_COUNTS_FREQ> o Warnings with unrecognized types <#TYPE_UNKNOWN> Log files analyzed * build.log total lines read 28834 total warnings found 2648 unique warnings found 617 Reference files analyzed * build-25000.log total lines read 25000 total warnings found 2618 unique warnings found 590 New warnings not found in reference files democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swing/JTabbedPane.java 1 javax/swing/JTable.java 5 javax/swing/JTree.java 4 javax/swing/text/JTextComponent.java 3 ~NONE~ 1 Warning counts, sorted alphabetically by location /usr/include/X11/IntrinsicP.h 1 /usr/include/langinfo.h 1 /usr/include/sys/cdefs.h 1 /usr/include/sys/param.h 2 back/ArrayTypeImpl.c 1 back/inStream.c 4 back/outStream.c 8 back/stream.c 4 bin/jexec.c 1 bin/parse_manifest.c 1 build/tools/compilefontconfig/CompileFontConfig.java 4 build/tools/dtdbuilder/DTDParser.java 2 build/tools/fontchecker/FontChecker.java 2 build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java 3 build/tools/javazic/Gen.java 23 build/tools/javazic/GenDoc.java 2 build/tools/javazic/Time.java 7 com/sun/java/util/jar/pack/bands.cpp 2 com/sun/java/util/jar/pack/coding.cpp 1928 com/sun/java/util/jar/pack/main.cpp 1 com/sun/java/util/jar/pack/unpack.cpp 32 com/sun/java/util/jar/pack/unpack.h 24 com/sun/java/util/jar/pack/utils.cpp 2 com/sun/java/util/jar/pack/zip.cpp 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c 5 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c 1 common/check_code.c 9 common/check_format.c 1 demo/jvmti/hprof/hprof_init.c 1 democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 hpi/native_threads/src/sys_api_td.c 1 instrument/JarFacade.c 1 java/io/canonicalize_md.c 2 java/io/io_util_md.h 8 java/lang/Class.c 1 java/lang/ClassLoader.c 2 java/lang/fdlibm/include/fdlibm.h 1 java/lang/fdlibm/src/e_jn.c 1 java/lang/fdlibm/src/e_pow.c 1 java/lang/fdlibm/src/e_sqrt.c 1 java/lang/fdlibm/src/s_ceil.c 1 java/lang/fdlibm/src/s_floor.c 1 java/lang/fdlibm/src/s_log1p.c 1 java/lang/java_props_md.c 3 java/lang/reflect/Proxy.c 1 java/net/Inet4AddressImpl.c 2 java/net/Inet6AddressImpl.c 3 java/net/NetworkInterface.c 1 java/net/PlainDatagramSocketImpl.c 6 java/net/linux_close.c 3 java/net/net_util_md.c 2 java/nio/Bits.c 8 java/nio/MappedByteBuffer.c 1 java/util/zip/zip_util.c 1 java/util/zip/zlib-1.1.3/inftrees.c 3 javavm/include/typedefs.h 8 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swi
Re: getting a handle on build warnings
FYI... I dug up my old wstats ksh script and ran it over a concatenation of the latest jdk7 build 30 logs for all 8 of builds done by Java Release Engineering (solaris-i586, solaris-x64, solaris-sparc, solaris-sparcv9, linux-i586, linux-x64, windows-i586, and windows-x64). Granted, these are OLD Linux systems with gcc 3.2, and lots of duplicates here. The problems with dealing with the C/C++ warnings is that the different compilers and different releases of the compilers create a bit of an unknown when trying to fix warnings. Fixing a warning from gcc4 might just trigger a new warning for some other reason from the Sun Studio compiler, can be frustrating. And using just a slightly newer or patched gcc or Sun Studio compiler might generate new warnings you haven't seen before. This has gotten better over time but continues to be an issue. A danger also lies in how a warning is fixed in native code that needs to work on all platforms and with different compilers, for example, adding a cast like '(long)' might shut up a warning, but could break Windows X64 where a long is 32bits not 64bits. People need to be very careful in the native code. At least with the javac warnings, fixing them is more concrete, and probably less risky ;^) I'm all in favor of fixing the warnings, just trying to make sure it's done safely. ;^) -kto - Warning Message Counts: -- 15790 ld warnings (contains 'ld:') 6686 C warnings (contains '[.]c[":]') 1616 C Include file warnings (contains '[.]h[":]') 9700 C++ warnings (contains '[.]cpp[":]') 0 C++ Include file warnings (contains '[.]hpp[":]') 4432 Java warnings (contains '.java:' or 'Note:' ) 0 VM warnings (contains 'VM warning:' ) 600 Javadoc warnings (contains ': warning -') 250 Compiler driver warnings (contains cc: or CC: or 'cl :') 59 GNU make warnings (contains '.gmk:' or 'akefile:' or '(ignored)' or starts with 'gnumake') 276 Shell warnings (contains ': not found' or 'awk:') 187 Build warnings (contains WARNING:) 312 Font warnings (contains 'entry is missing') - 39908 Total of above warnings 29252 Messages that appear to be duplicates 18 Remaining errors not counted warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist /usr/ccs/bin/as: "/export2/BUILD_AREA/jdk7/hotspot/src/os_cpu/solaris_sparc/vm/solaris_sparc.s", line 86: warning: label in delay slot (follows CTI) warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist warning: package com.sun.java.swing.plaf does not exist warning: package com.sun.java.swing.plaf.gtk does not exist Top 20 'src/' files mentioned in warning messages: - 7972 src/share/native/com/sun/java/util/jar/pack/coding.cpp 2062 src/closed/share/classes/sun/jdbc/odbc/JdbcOdbc.c 1278 src/share/native/com/sun/java/util/jar/pack/unpack.cpp 1188 src/share/classes/sun/corba/Bridge.java 1096 src/solaris/native/sun/awt/gtk2_interface.c 888 src/closed/share/native/sun/java2d/cmm/kcms/evalth13.c 720 src/share/native/com/sun/java/util/jar/pack/bands.h 276 src/share/native/com/sun/java/util/jar/pack/unpack.h 276 src/build/tools/javazic/Gen.java 272 src/closed/share/native/sun/java2d/cmm/kcms/evalth14.c 252 src/share/classes/sun/nio/ch/FileChannelImpl.java 204 src/share/native/com/sun/java/util/jar/pack/bytes.h 204 src/share/classes/org/omg/CORBA/ORB.java 192 src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java 170 src/share/native/sun/security/jgss/wrapper/GSSLibStub.c 140 src/share/native/com/sun/java/util/jar/pack/zip.cpp 136 src/share/native/sun/awt/medialib/mlib_ImageAffineEdge.c 128 src/share/native/sun/font/layout/LEGlyphStorage.h 114 src/share/classes/javax/sql/rowset/BaseRowSet.java 108 src/share/classes/javax/rmi/CORBA/GetORBPropertiesFileAction.java Jonathan Gibbons wrote: I've written a prog
Re: getting a handle on build warnings
there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon JDK Build Warnings * Comparison against reference results o New warnings not found in reference files <#REF_DELTA_LOCNS> * Warnings categorized by location o Warning counts, sorted alphabetically by location <#LOCN_COUNTS_ALPHA> o Warning counts, sorted by frequency of location <#LOCN_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> * Warnings categorized by type o Warning counts, sorted alphabetically by type <#TYPE_COUNTS_ALPHA> o Warning counts, sorted by frequency of type <#TYPE_COUNTS_FREQ> o Warnings with unrecognized types <#TYPE_UNKNOWN> Log files analyzed * build.log total lines read 28834 total warnings found 2648 unique warnings found 617 Reference files analyzed * build-25000.log total lines read 25000 total warnings found 2618 unique warnings found 590 New warnings not found in reference files democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swing/JTabbedPane.java 1 javax/swing/JTable.java 5 javax/swing/JTree.java 4 javax/swing/text/JTextComponent.java 3 ~NONE~ 1 Warning counts, sorted alphabetically by location /usr/include/X11/IntrinsicP.h 1 /usr/include/langinfo.h 1 /usr/include/sys/cdefs.h 1 /usr/include/sys/param.h 2 back/ArrayTypeImpl.c 1 back/inStream.c 4 back/outStream.c 8 back/stream.c 4 bin/jexec.c 1 bin/parse_manifest.c 1 build/tools/compilefontconfig/CompileFontConfig.java 4 build/tools/dtdbuilder/DTDParser.java 2 build/tools/fontchecker/FontChecker.java 2 build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java 3 build/tools/javazic/Gen.java 23 build/tools/javazic/GenDoc.java 2 build/tools/javazic/Time.java 7 com/sun/java/util/jar/pack/bands.cpp 2 com/sun/java/util/jar/pack/coding.cpp 1928 com/sun/java/util/jar/pack/main.cpp 1 com/sun/java/util/jar/pack/unpack.cpp 32 com/sun/java/util/jar/pack/unpack.h 24 com/sun/java/util/jar/pack/utils.cpp 2 com/sun/java/util/jar/pack/zip.cpp 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c 5 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c 1 common/check_code.c 9 common/check_format.c 1 demo/jvmti/hprof/hprof_init.c 1 democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 hpi/native_threads/src/sys_api_td.c 1 instrument/JarFacade.c 1 java/io/canonicalize_md.c 2 java/io/io_util_md.h 8 java/lang/Class.c 1 java/lang/ClassLoader.c 2 java/lang/fdlibm/include/fdlibm.h 1 java/lang/fdlibm/src/e_jn.c 1 java/lang/fdlibm/src/e_pow.c 1 java/lang/fdlibm/src/e_sqrt.c 1 java/lang/fdlibm/src/s_ceil.c 1 java/lang/fdlibm/src/s_floor.c 1 java/lang/fdlibm/src/s_log1p.c 1 java/lang/java_props_md.c 3 java/lang/reflect/Proxy.c 1 java/net/Inet4AddressImpl.c 2 java/net/Inet6AddressImpl.c 3 java/net/NetworkInterface.c 1 java/net/PlainDatagramSocketImpl.c 6 java/net/linux_close.c 3 java/net/net_util_md.c 2 java/nio/Bits.c 8 java/nio/MappedByteBuffer.c 1 java/util/zip/zip_util.c 1 java/util/zip/zlib-1.1.3/inftrees.c 3 javavm/include/typedefs.h 8 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swing/JTabbedPane.java 1 javax/swing/JTable.java 5 javax/swing/JTree.java 4 javax/swing/text/
Re: getting a handle on build warnings
. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon JDK Build Warnings * Comparison against reference results o New warnings not found in reference files <#REF_DELTA_LOCNS> * Warnings categorized by location o Warning counts, sorted alphabetically by location <#LOCN_COUNTS_ALPHA> o Warning counts, sorted by frequency of location <#LOCN_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> o Warning counts, sorted alphabetically by location directory <#LOCN_DIR_COUNTS_ALPHA> o Warning counts, sorted by frequency of location directory <#LOCN_DIR_COUNTS_FREQ> * Warnings categorized by type o Warning counts, sorted alphabetically by type <#TYPE_COUNTS_ALPHA> o Warning counts, sorted by frequency of type <#TYPE_COUNTS_FREQ> o Warnings with unrecognized types <#TYPE_UNKNOWN> Log files analyzed * build.log total lines read 28834 total warnings found 2648 unique warnings found 617 Reference files analyzed * build-25000.log total lines read 25000 total warnings found 2618 unique warnings found 590 New warnings not found in reference files democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swing/JTabbedPane.java 1 javax/swing/JTable.java 5 javax/swing/JTree.java 4 javax/swing/text/JTextComponent.java 3 ~NONE~ 1 Warning counts, sorted alphabetically by location /usr/include/X11/IntrinsicP.h 1 /usr/include/langinfo.h 1 /usr/include/sys/cdefs.h 1 /usr/include/sys/param.h 2 back/ArrayTypeImpl.c 1 back/inStream.c 4 back/outStream.c 8 back/stream.c 4 bin/jexec.c 1 bin/parse_manifest.c 1 build/tools/compilefontconfig/CompileFontConfig.java 4 build/tools/dtdbuilder/DTDParser.java 2 build/tools/fontchecker/FontChecker.java 2 build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java 3 build/tools/javazic/Gen.java 23 build/tools/javazic/GenDoc.java 2 build/tools/javazic/Time.java 7 com/sun/java/util/jar/pack/bands.cpp 2 com/sun/java/util/jar/pack/coding.cpp 1928 com/sun/java/util/jar/pack/main.cpp 1 com/sun/java/util/jar/pack/unpack.cpp 32 com/sun/java/util/jar/pack/unpack.h 24 com/sun/java/util/jar/pack/utils.cpp 2 com/sun/java/util/jar/pack/zip.cpp 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c 1 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c 5 com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c 1 common/check_code.c 9 common/check_format.c 1 demo/jvmti/hprof/hprof_init.c 1 democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp 1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 hpi/native_threads/src/sys_api_td.c 1 instrument/JarFacade.c 1 java/io/canonicalize_md.c 2 java/io/io_util_md.h 8 java/lang/Class.c 1 java/lang/ClassLoader.c 2 java/lang/fdlibm/include/fdlibm.h 1 java/lang/fdlibm/src/e_jn.c 1 java/lang/fdlibm/src/e_pow.c 1 java/lang/fdlibm/src/e_sqrt.c 1 java/lang/fdlibm/src/s_ceil.c 1 java/lang/fdlibm/src/s_floor.c 1 java/lang/fdlibm/src/s_log1p.c 1 java/lang/java_props_md.c 3 java/lang/reflect/Proxy.c 1 java/net/Inet4AddressImpl.c 2 java/net/Inet6AddressImpl.c 3 java/net/NetworkInterface.c 1 java/net/PlainDatagramSocketImpl.c 6 java/net/linux_close.c 3 java/net/net_util_md.c 2 java/nio/Bits.c 8 java/nio/MappedByteBuffer.c 1 java/util/zip/zip_util.c 1 java/util/zip/zlib-1.1.3/inftrees.c 3 javavm/include/typedefs.h 8 javax/swing/JColorChooser.java 1 javax/swing/JComponent.java 4 javax/swing/JInternalFrame.java 2 javax/swing/JList.java 4 javax/swing/JPopupMenu.java 1 javax/swing/JTabbedPane.java 1 javax/swing/JTable.java 5 javax/swing/JTree.java 4 javax/swing/text/JTextComponent.java 3 sun/awt/awt_DrawingSurface.c 1 sun/awt/awt_Fon
Re: getting a handle on build warnings
Was this a Windows X86 build? --- I'll file a bug on the serviceability related files, I thought we had fixed all our warnings. e.g. these: back/ArrayTypeImpl.c1 back/inStream.c 4 back/outStream.c8 back/stream.c 4 demo/jvmti/hprof/hprof_init.c 1 democlasses/demo/jvmti/hprof/src/hprof_init.c 1 democlasses/demo/jvmti/waiters/src/Agent.cpp1 democlasses/demo/jvmti/waiters/src/waiters.cpp 2 instrument/JarFacade.c 1 transport/socket/socket_md.c3 If we chip away at this, I think we can clean it up over time. -kto Jonathan Gibbons wrote: I've written a program to analyze the warnings in a build log, containing most of the ideas I outlined earlier, and more. Right now, a "warning" is defined as a line containing the string "warning" with false positives filtered out (e.g. a reference to a file called warning.png) It can generate a report in plain text or html, containing any/all of the following: - comparison against a reference log, such as the log for an earlier promoted build - a summary of the warnings, grouped by the location contained in the warning - a summary of the warnings, grouped by the type of the warning The summaries are given sorted both alphabetically and by frequency. I've attached a sample of the output. The input was the log for a build on my laptop. For the purposes of testing, the "reference" was the same log truncated to 25000 lines. The big surprise: One file is responsible for nearly 72% of all the warnings in this build: 1928 warnings out of a total of 2684! The file in question is com/sun/java/util/jar/pack/coding.cpp The corollary is good news for everyone else; there are fewer warnings through the rest of the build than I expected, with only 14 files having 10 or more warnings. But, there are still over 150 files containing warnings :-( -- Jon Jonathan Gibbons wrote: Well, here's an unexpected initial result. I just ran a build of langtools+jdk on my ubuntu laptop. I got a whopping 2658 warnings!! [Those who volunteered to help get rid of all the warnings, don't all step back at once!] But surprisingly, after a quick "sort -u", only 625 of them are unique. So that means we get on average a 4x bang for the buck for each warning we fix :-) -- Jon On Jul 11, 2008, at 11:02 AM, Jonathan Gibbons wrote: Depending on what lint options you use, deprecation warnings are typically reported as a single "Note:" at the end of the compilation, rather than as individual warning messages. Ideally, they should go too, but for now, I'd settle for removing messages that show up as diagnostics in IDEs, emacs, etc. For my part, I work mostly in the langtools area, and we are having a general background effort to clean up the code there. The goal is to clean the code and then use -Werror to treat any reappearance of warnings as errors. -- Jon On Jul 11, 2008, at 10:52 AM, Rob Ross wrote: Just curious, would part of this revision process entail removing calls to deprecated methods and replacing them with their documented replacement methods? There are many warnings about calls to deprecated methods in the OpenJDK code. Rob Ross, Lead Software Engineer E! Networks --- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote: On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non-intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon JDK Build Warnings
Re: getting a handle on build warnings
I've written a program to analyze the warnings in a build log, containing most of the ideas I outlined earlier, and more. Right now, a "warning" is defined as a line containing the string "warning" with false positives filtered out (e.g. a reference to a file called warning.png) It can generate a report in plain text or html, containing any/all of the following: - comparison against a reference log, such as the log for an earlier promoted build - a summary of the warnings, grouped by the location contained in the warning - a summary of the warnings, grouped by the type of the warning The summaries are given sorted both alphabetically and by frequency. I've attached a sample of the output. The input was the log for a build on my laptop. For the purposes of testing, the "reference" was the same log truncated to 25000 lines. The big surprise: One file is responsible for nearly 72% of all the warnings in this build: 1928 warnings out of a total of 2684! The file in question is com/sun/java/util/jar/pack/coding.cpp The corollary is good news for everyone else; there are fewer warnings through the rest of the build than I expected, with only 14 files having 10 or more warnings. But, there are still over 150 files containing warnings :-( -- Jon Jonathan Gibbons wrote: Well, here's an unexpected initial result. I just ran a build of langtools+jdk on my ubuntu laptop. I got a whopping 2658 warnings!! [Those who volunteered to help get rid of all the warnings, don't all step back at once!] But surprisingly, after a quick "sort -u", only 625 of them are unique. So that means we get on average a 4x bang for the buck for each warning we fix :-) -- Jon On Jul 11, 2008, at 11:02 AM, Jonathan Gibbons wrote: Depending on what lint options you use, deprecation warnings are typically reported as a single "Note:" at the end of the compilation, rather than as individual warning messages. Ideally, they should go too, but for now, I'd settle for removing messages that show up as diagnostics in IDEs, emacs, etc. For my part, I work mostly in the langtools area, and we are having a general background effort to clean up the code there. The goal is to clean the code and then use -Werror to treat any reappearance of warnings as errors. -- Jon On Jul 11, 2008, at 10:52 AM, Rob Ross wrote: Just curious, would part of this revision process entail removing calls to deprecated methods and replacing them with their documented replacement methods? There are many warnings about calls to deprecated methods in the OpenJDK code. Rob Ross, Lead Software Engineer E! Networks --- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote: On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non-intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon Title: JDK Build Warnings JDK Build Warnings Comparison against reference results New warnings not found in reference files Warnings categorized by location Warning counts, sorted alphabetically by location Warning counts, sorted by frequency of location Warning counts, sorted alphabetically by location directory Warning counts, sorted by frequency of location directory Warning counts, sorted alphabetically by location directory Warning counts, sorted by frequency of location directory Warnings categorized by type Warning counts, sorted alphabetically by type Warning counts, sorted by frequency of type Warnings with unrecognized types Log files ana
Re: getting a handle on build warnings
Well, here's an unexpected initial result. I just ran a build of langtools+jdk on my ubuntu laptop. I got a whopping 2658 warnings!! [Those who volunteered to help get rid of all the warnings, don't all step back at once!] But surprisingly, after a quick "sort -u", only 625 of them are unique. So that means we get on average a 4x bang for the buck for each warning we fix :-) -- Jon On Jul 11, 2008, at 11:02 AM, Jonathan Gibbons wrote: Depending on what lint options you use, deprecation warnings are typically reported as a single "Note:" at the end of the compilation, rather than as individual warning messages. Ideally, they should go too, but for now, I'd settle for removing messages that show up as diagnostics in IDEs, emacs, etc. For my part, I work mostly in the langtools area, and we are having a general background effort to clean up the code there. The goal is to clean the code and then use -Werror to treat any reappearance of warnings as errors. -- Jon On Jul 11, 2008, at 10:52 AM, Rob Ross wrote: Just curious, would part of this revision process entail removing calls to deprecated methods and replacing them with their documented replacement methods? There are many warnings about calls to deprecated methods in the OpenJDK code. Rob Ross, Lead Software Engineer E! Networks --- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote: On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non-intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon
Re: getting a handle on build warnings
Depending on what lint options you use, deprecation warnings are typically reported as a single "Note:" at the end of the compilation, rather than as individual warning messages. Ideally, they should go too, but for now, I'd settle for removing messages that show up as diagnostics in IDEs, emacs, etc. For my part, I work mostly in the langtools area, and we are having a general background effort to clean up the code there. The goal is to clean the code and then use -Werror to treat any reappearance of warnings as errors. -- Jon On Jul 11, 2008, at 10:52 AM, Rob Ross wrote: Just curious, would part of this revision process entail removing calls to deprecated methods and replacing them with their documented replacement methods? There are many warnings about calls to deprecated methods in the OpenJDK code. Rob Ross, Lead Software Engineer E! Networks --- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote: On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non-intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon
Re: getting a handle on build warnings
Just curious, would part of this revision process entail removing calls to deprecated methods and replacing them with their documented replacement methods? There are many warnings about calls to deprecated methods in the OpenJDK code. Rob Ross, Lead Software Engineer E! Networks --- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jul 11, 2008, at 10:43 AM, Jonathan Gibbons wrote: On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non-intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon
Re: getting a handle on build warnings
On Jul 11, 2008, at 10:00 AM, Thorbjørn Ravn Andersen wrote: Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there Thank you. Getting rid of the actual warnings will require cooperation from the teams who are responsible for the various parts of the code. In some cases, there may be resistance, since stability is sometimes preferred over "no warnings". That being said, what I'm hoping to achieve with this discussion and any related effort is a non- intrusive way of gathering information about warnings, so that we have a better understanding of where the warnings are, in what areas of the code and in which source files. That way, we can work with the teams involved to see if there is interest in reducing their warning count in as safe a way as possible. Any assistance in getting to that point would be welcome. (Note that anyone contributing to OpenJDK must first sign the Sun Contributor Agreement; you can find details at http://sca.dev.java.net.) -- Jon
Re: getting a handle on build warnings
Jonathan Gibbons skrev den 11-07-2008 13:52: Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. Personally I'd like there to be no warnings at all, and would like to contribute work to get there
Re: getting a handle on build warnings
On Jul 11, 2008, at 2:29 AM, Volker Simonis wrote: On 7/10/08, Jonathan Gibbons <[EMAIL PROTECTED]> wrote: The JDK build generates a whole lot of warnings along the way. This is bad because these warnings can sometimes mask real errors. For a variety of reasons, it appears to be hard to try and get rid of all the warnings, so this message is about a set of possible ideas to try and get some control over the problem, by providing a relatively general framework to use within the build, to minimize the introduction of new warnings, and by providing a reporting framework for those developers that *are* interested in reducing the warnings in their code. This would be nice! 1. Collecting warnings. The simplest, easiest way to collect the warnings is to save the output from a build, for subsequent processing by any new tools we provide. David Herron has also suggested we could prefix the build macros for selected commands like cc, javac, javadoc etc such that the output from each invocation of the command is appended to a log, perhaps a directory specific log. For example, the macro to invoke javac could instead invoke savelog -a $(pwd)/javac.log javac ... where savelog is a new command to run a subcommand and save its output. Whichever way we go, the first step in getting a handle on warnings would be to save the output from the commands generating the warnings. I always build with "make jvmg 2>&1 | tee ../../hotspot_c2_debug.log". This way I get the whole output produced by the build in the terminal window as well as in a log-file. Perhaps the easiest thing would be to add this feature to a top-level Makefile such that it always calls subsequent Makefiles in a way that redirects their output to a file (e.g. .log). Yes, that technique can work well. But either way, the next step is to try writing the code to analyze the build log, to see how far the general idea can be taken, and how much interest there is to track/fix warnings. -- Jon
Re: getting a handle on build warnings
On 7/10/08, Jonathan Gibbons <[EMAIL PROTECTED]> wrote: > The JDK build generates a whole lot of warnings along the way. This is > bad because these warnings can sometimes mask real errors. For a > variety of reasons, it appears to be hard to try and get rid of all the > warnings, so this message is about a set of possible ideas to try and > get some control over the problem, by providing a relatively general > framework to use within the build, to minimize the introduction of new > warnings, and by providing a reporting framework for those developers > that *are* interested in reducing the warnings in their code. > This would be nice! > 1. Collecting warnings. > > The simplest, easiest way to collect the warnings is to save the output > from > a build, for subsequent processing by any new tools we provide. > > David Herron has also suggested we could prefix the build macros for > selected commands like cc, javac, javadoc etc such that the output from > each invocation of the command is appended to a log, perhaps a directory > specific log. For example, the macro to invoke javac could instead invoke >savelog -a $(pwd)/javac.log javac ... > where savelog is a new command to run a subcommand and save its output. > > Whichever way we go, the first step in getting a handle on warnings would > be to save the output from the commands generating the warnings. I always build with "make jvmg 2>&1 | tee ../../hotspot_c2_debug.log". This way I get the whole output produced by the build in the terminal window as well as in a log-file. Perhaps the easiest thing would be to add this feature to a top-level Makefile such that it always calls subsequent Makefiles in a way that redirects their output to a file (e.g. .log).
Re: getting a handle on build warnings
+1 from me. --- It might help that when people do remove some of the more tricky warnings, that they send a short email on how they did it. I remember having to walk down the hall to see Peter Ahe a few times when I was trying to get rid of some of the trickier warnings in some of my java code. Using the annotation to suppress the warning should be a last resort. -kto Jonathan Gibbons wrote: The point is noted, but it seems to me that it would be better to work on removing warnings rather than making it even easier to continue ignoring them :-) With the possible exception of the obnoxious proprietary API warnings from javac (which typically do not occur in the build anyway), all warnings from javac can be eliminated one way or another, and we should be doing all we can to have developers eliminate the warnings in the code for which they are responsible. Even if we can't clean all the warnings from all the files, I think it is reasonable to remove all the warnings from any file a developer edits. -- Jon Martin Buchholz wrote: One significant simple annoyance is that compile errors are hard to find amongst the mass of warnings, because errors are not identified as such. It would be very nice if errors were prefixed by "error:" the same way that warnings are prefixed by "warning:", making them easy to search for. Martin
Re: getting a handle on build warnings
The point is noted, but it seems to me that it would be better to work on removing warnings rather than making it even easier to continue ignoring them :-) With the possible exception of the obnoxious proprietary API warnings from javac (which typically do not occur in the build anyway), all warnings from javac can be eliminated one way or another, and we should be doing all we can to have developers eliminate the warnings in the code for which they are responsible. Even if we can't clean all the warnings from all the files, I think it is reasonable to remove all the warnings from any file a developer edits. -- Jon Martin Buchholz wrote: One significant simple annoyance is that compile errors are hard to find amongst the mass of warnings, because errors are not identified as such. It would be very nice if errors were prefixed by "error:" the same way that warnings are prefixed by "warning:", making them easy to search for. Martin
Re: getting a handle on build warnings
One significant simple annoyance is that compile errors are hard to find amongst the mass of warnings, because errors are not identified as such. It would be very nice if errors were prefixed by "error:" the same way that warnings are prefixed by "warning:", making them easy to search for. Martin
getting a handle on build warnings
The JDK build generates a whole lot of warnings along the way. This is bad because these warnings can sometimes mask real errors. For a variety of reasons, it appears to be hard to try and get rid of all the warnings, so this message is about a set of possible ideas to try and get some control over the problem, by providing a relatively general framework to use within the build, to minimize the introduction of new warnings, and by providing a reporting framework for those developers that *are* interested in reducing the warnings in their code. 1. Collecting warnings. The simplest, easiest way to collect the warnings is to save the output from a build, for subsequent processing by any new tools we provide. David Herron has also suggested we could prefix the build macros for selected commands like cc, javac, javadoc etc such that the output from each invocation of the command is appended to a log, perhaps a directory specific log. For example, the macro to invoke javac could instead invoke savelog -a $(pwd)/javac.log javac ... where savelog is a new command to run a subcommand and save its output. Whichever way we go, the first step in getting a handle on warnings would be to save the output from the commands generating the warnings. 2. Analyzing and normalizing warnings. Warnings can be divided into two groups: - those we know how to and want to deal with, and - those we don't. Ignore the latter group for now. Perhaps in time we'll figure out how to deal with them and become interested in dealing with them. We can select the warnings in the first group with grep or regular expressions. Then we want to normalize the warnings. Normalizing a warning consists of a number of steps: - remove any information specific to that instance of the build. Typically, this will mean the head of any user-specific paths, such as absolute paths on the build machine. - remove any information that may not be inherent to the warning Typically, this will mean line numbers in the build. Someone could edit the text in the source file ahead of the warning, and change the line number used in the warning. This should not change the normalized form of the warning - adjust the location of the warning to be relative to one of the standard "subroots" within the tree, such as "src/share/classes", "src/PLATFORM/classes", etc. In addition, standardize file separators in the location of the warning. At the end of the normalization, warnings should all begin with a location, such as the following made up examples, java/lang/String.java: warning: unchecked type com/sun/tools/javac/Main.java: warning: using deprecated method Sorting the overall set of warnings would be good too. 3. Reporting and further analysis If Release Engineering could produce a normalized list of warnings for each promoted build, it would be possible for a developer to compare the results of any new build against the "official" set of currently known warnings, to see if any new warnings have been introduced. PIT testing could verify that no new warnings have been introduced, and possibly give waivers for any justifiable new warnings. The "official" set of currently known warnings could be posted on OpenJDK, so that OpenJDK developers outside of Sun could compare their results to the published results. Developers could put "assertions" into the build to assert that portions of the code are warning-free. -Werror achieves that to a limited extent but doesn't work on tools like javadoc, which processes large amounts of code which may not all be warning-free. From the normalized list of warnings, it would be possible a summary table, grouped by package, and sorted either alphabetically or by quantity. This way, we could see where are the worst offending source files, and perhaps use that as motivation for fixing warnings. Summary Dealing with warnings has proven almost impossibly difficult over the years. The ideas presented here make it simpler to deal with the problems by identifying warnings that we know how to fix, in areas where we are interested in fixing them. In addition, it provides a way we can ensure that the situation doesn't get any worse, going forward. -- Jon
