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
k.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
age-
> 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
&
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, disabl
> 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
>
>
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.
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*, un
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, E
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 descrip
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/N
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
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_
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 structu
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
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/0
> 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 trac
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
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 e
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 w
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
unfortunatel
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 warni
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: lef
/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;
> >>
sed 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 progr
ort 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
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 an
een/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&#
lashscreen_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 buil
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 doclin
s.
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
ly 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 warni
ter 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 c
014-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 c
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
eal 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 paramete
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 param
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 |
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 iss
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
;[.]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 warni
r '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 (c
r '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)
rest
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://s
27;.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
tance 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
ibuting to OpenJDK must first sign the Sun
Contributor Agreement;
you can find details at http://sca.dev.java.net.)
-- Jon
JDK Build Warnings
*
JDK must first sign the Sun
Contributor Agreement;
you can find details at http://sca.dev.java.net.)
-- Jon
JDK Build Warnings
* Comparison aga
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 c
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
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,
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
---
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 interes
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
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
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 messag
+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.
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 warn
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
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 ove
59 matches
Mail list logo
