[OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile jchuff.c

[Adam Farley8]

 Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile 
jchuff.cErik Joelsson to: Adam Farley8 01/02/2018 17:06
Cc: build-dev, David Holmes, John Paul Adrian Glaubitz, Magnus Ihse Bursie
From: Erik Joelsson <erik.joelsson at oracle.com>
To: Adam Farley8 <adam.farley at uk.ibm.com>
Cc: build-dev <build-dev at openjdk.java.net>, David Holmes 
<david.holmes at oracle.com>, John Paul Adrian Glaubitz 
<glaubitz at physik.fu-berlin.de>, Magnus Ihse Bursie 
<magnus.ihse.bursie at oracle.com>
 

> Am I understanding this correctly that it's really not tied to a gcc 
version
> but a cpu architecture, so it's only really affecting s390x? 

I'm saying it is tied to a combination of CPU architecture and gcc 
version.
Any combination of the affected gcc versions (4.8.5, 5.4.0) and affected
platforms (zLinux, ppcle Linux) see this error.

x86 Linux is not affected, not are gcc versions equal to (or, I assume, 
later 
than) 7.2.1.

> Are you also saying that gcc 7.2.1 is also affected but with a different 

> message? I'm fine with disabling this warning conditional on s390x, no 
need 
> for specific gcc versions.

I was unclear. 7.2.1 fails my unit test with a different warning, but a 
build 
I ran proves that this warning doesn't fail the build.

That being said, the addition of this option to a 7.2.1 test didn't seem 
to 
break anything, so we should be fine to just stick 
"DISABLED_WARNINGS_gcc := clobbered array-bounds" into Awt2dLibraries.gmk. 


> This discussion has already taken more time than it really warrants. :)

Agreed. :)

> Regarding warning chasing. I agree that we it's not feasible to chase 
down every 
> warning in every version of GCC, or any other toolchain, but I also 
think that 
> for platforms/configurations where people are actively developing 
changes for 
> OpenJDK, it makes sense to try to keep it clean. This helps prevent new 
code from 
> introducing warnings. For the configurations Oracle use, we keep a 
strict -Werror 
> policy because we want the code to be clean. I'm fine with other users 
trying to 
> keep the same standards on their configurations, but knowing that it 
will be their 
> responsibility to keep up to date. I also think we need to be reasonably 
fine grained 
> in when we disable warnings. Specifying every affected version of a 
toolchain is too 
> much, but if there are specific well defined limits to where the 
disabling relevant, 
> then I think we should use them, within reason. This also helps with 
keeping track 
> of why a particular warning is disabled in a future attempt to fix them.

I agree with all of this. Well put. :)

> On the other hand, if you are just building OpenJDK to produce binaries, 
without 
> producing and up streaming new code changes, there really isn't much 
need for 
> making the effort of trying to keep things clean, and trying to do so 
will likely 
> just end up being more work than it's worth.
> /Erik

I'm building OpenJDK to test fixes and new features, which I will 
eventually contribute
to OpenJDK. I consider this to be one of those fixes. One fix at a time. 
:)

Given all of this, I ask for a volunteer to raise a bug so we can 
integrate this change 
into JDK8 (as it's still very popular), and JDK. 

10 would be great too, though I understand it's locked against all but the 
worst bugs.
9 is optional, as it's soon to be replaced by 10.

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180207/0f795911/attachment.html>