On 2018-01-17 15:07, Adam Farley8 wrote:
If this is the consensus, then perhaps we should consider setting
--disable-warnings-as-errors by default (in the code), rather than
depending on the user using an option which is not part of the formal
build instructions.
I'm not sure why.
Because the
Hi!
On 01/18/2018 06:27 PM, Erik Joelsson wrote:
When adding a disabled warning like this, we need to also add a clear comment
describing why it's necessary. In this case it's caused by a bug in GCC and only
affects certain versions. Otherwise, we will likely try to remove them later and
Hello Adam,
When adding a disabled warning like this, we need to also add a clear
comment describing why it's necessary. In this case it's caused by a bug
in GCC and only affects certain versions. Otherwise, we will likely try
to remove them later and without information on why it was added,
Hi All
I sent an email to the 2d-dev list yesterday, but I'll respond here as
well
so you guys know I'm not ignoring you. :)
> This is all correct, thanks David!
>
> For the official toolchains (basically what Oracle builds with), we very
> much like to keep warnings-as-errors active,
This is all correct, thanks David!
For the official toolchains (basically what Oracle builds with), we very
much like to keep warnings-as-errors active, because it's a very
valuable tool in keeping the code healthy. For other toolchains, it
depends, as David says.
We have a mechanism for
Adam,
Erik or Magnus from the build team should step in here if this
information is wrong but AFAIK the intent is that using the official
toolchains the OpenJDK will build out-of-the-box using the supplied
instructions and whatever the default settings are (which ideally would
be without any
>> Switching the OPTIMIZATION to LOW will solve this at a stroke.
>
>And regress performance for all platforms I expect in a case where
>performance matters ..
>in order to work around a gcc bug ? I don't think so.
I wasn't considering the performance impact on java jpeg. A fair
statement.
> Switching the OPTIMIZATION to LOW will solve this at a stroke.
And regress performance for all platforms I expect in a case where
performance matters ..
in order to work around a gcc bug ? I don't think so.
Disabling the specific error with the specific tool chain is the only
acceptable
On 01/17/2018 03:07 PM, Adam Farley8 wrote:
Because the default build instructions don't work in this scenario, and
if all the effort to impliment a clone-config-make model was intended to
encourage more users to attempt a local build (in order to try their hand
at a fixing a bug themselves or
>> If this is the consensus, then perhaps we should consider setting
>> --disable-warnings-as-errors by default (in the code), rather than
>> depending on the user using an option which is not part of the formal
>> build instructions.
>I'm not sure why.
Because the default build instructions
On 01/17/2018 01:56 PM, Adam Farley8 wrote:
If this is the consensus, then perhaps we should consider setting
--disable-warnings-as-errors by default (in the code), rather than
depending on the user using an option which is not part of the formal
build instructions.
I'm not sure why. Building
Hi John, David,
>> If you compile jchuff.c (part of javajpeg) without
>> "--disable-warnings-as-errors",
>> then you get an error that kills the build. This is seen in these
>> circumstances:
>Last time this particular discussion came up, the conclusion was that
>hunting for warnings is a lost
Hi Adam,
This seems to be a gcc bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
I'm assuming that the code is actually written in such a way that the
index will never actually go negative (due to what has been written
previously).
The right fix here would be to disable the warning
Hi Adam!
On 01/17/2018 12:50 PM, Adam Farley8 wrote:
If you compile jchuff.c (part of javajpeg) without
"--disable-warnings-as-errors",
then you get an error that kills the build. This is seen in these
circumstances:
Last time this particular discussion came up, the conclusion was that
Hi All,
If you compile jchuff.c (part of javajpeg) without
"--disable-warnings-as-errors",
then you get an error that kills the build. This is seen in these
circumstances:
Build: JDK9
gcc and g++ Version: 4.8.5
Platform: zLinux 64bit (s390x)
The error message is:
15 matches
Mail list logo
