8304295: harfbuzz build fails with GCC 7 after JDK-8301998

[caojoshua]

Builds successfully with GCC 7

gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8304295: harfbuzz build fails with GCC 7 after JDK-8301998

Reviewers

• Aleksey Shipilev (@shipilev - Reviewer) ⚠️ Review applies to 51e9a59f
• Erik Joelsson (@erikj79 - Reviewer)
• Sergey Bylokhov (@mrserb - Reviewer)
• Julian Waters (@TheShermanTanker - Committer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13253/head:pull/13253
$ git checkout pull/13253

Update a local copy of the PR:
$ git checkout pull/13253
$ git pull https://git.openjdk.org/jdk.git pull/13253/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13253

View PR using the GUI difftool:
$ git pr show -t 13253

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13253.diff

[bridgekeeper]

👋 Welcome back caojoshua! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[caojoshua]

Bot is not filling in the PR. Did I input something wrong? Edit: nevermind, its good now

[openjdk]

@caojoshua The following labels will be automatically applied to this pull request:

• build
• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (d2218410)
• 00: Full (51e9a59f)

[mrserb]

If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.

[erikj79]

If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.

The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.

If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.

[mrserb]

If we will going forward with this patch, can we exclude the warning for the old compilers only? as was mentioned in the JBS the gcc10+ compiles that code fine.

The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.

If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.

Isnt it is possible to check the TOOLCHAIN_TYPE+TOOLCHAIN_VERSION as we did here?:
3476724
Or we do not set such props for gcc?

[shipilev]

I agree with Erik, we don't need to bother with excluding a particular compiler version here. Reading the JBS issue, I believe Kim suggested the same. This PR fixes the builds for me with GCC 7, so I am happy to approve. Someone from client-libs should ack this too, and we have @mrserb among us already :)

[openjdk]

@caojoshua This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8304295: harfbuzz build fails with GCC 7 after JDK-8301998

Reviewed-by: shade, erikj, serb, jwaters

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 20 new commits pushed to the master branch:

• a19b28a: 8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick
• 8eb4e7e: 8277501: Revisit PathFileObject.getCharContent and friends
• abfb900: 8304028: Port fdlibm IEEEremainder to Java
• a565be4: 8297605: improve DelayQueue removal method javadoc
• cccb019: 8304928: Optimize ClassDesc.resolveConstantDesc
• bdbf8fc: 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value
• 4a5d7ca: 8305227: [s390x] build broken after JDK-8231349
• dae1ab3: 8304844: JFR: Missing disk parameter in ActiveRecording event
• e012685: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed: java/lang/Long$LongCache must be initialized
• fe42312: 8304820: Statically allocate ObjectSynchronizer mutexes
• ... and 10 more: https://git.openjdk.org/jdk/compare/83cf28f99639d80e62c4031c4c9752460de5f36c...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@shipilev, @erikj79, @mrserb, @TheShermanTanker) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[shipilev]

I have an editorial note, though, @caojoshua: the bug says "VM build fails", but Harfbuzz is not technically part of VM. I understand it was like that before you took it. It would be better to rename the bug and this PR to "Build fails with GCC 7 after JDK-8301998", before it leaked into the permanent history of commits :)

[erikj79]

The build system doesn't have a convenient way of selectively disable warnings for different compiler versions. I recommend against trying to implement that here.
If this library is all third-party code, does it really matter that much if we disable another warning? We aren't responsible for keeping this source warning free as we can't make changes to it to anyway.

Isnt it is possible to check the TOOLCHAIN_TYPE+TOOLCHAIN_VERSION as we did here?: 3476724 Or we do not set such props for gcc?

As I said, it's possible, but inconvenient, and IMO not worth it for just disabling a warning. The linked example changes an optimization flag to avoid a compiler bug. That seems like a severe enough consequence to warrant such construct in the build. We want to avoid having a large amount of compiler version checks in the makefiles. In make we can only easily compare versions for equality and not ranges.

That said, it may be worth adding a comment that this warning has only been observed with GCC 7. That will help in the future when someone tries to remove disabled warnings.

[mrserb]

That said, it may be worth adding a comment that this warning has only been observed with GCC 7. That will help in the future when someone tries to remove disabled warnings.

Then the comment is better than nothing.

[caojoshua]

/summary harfbuzz build fails with GCC 7 after JDK-8301998

[openjdk]

@caojoshua Setting summary to harfbuzz build fails with GCC 7 after JDK-8301998

[caojoshua]

Added a comment as suggested by @erikj79

I incorrectly used the /summary command. Turns out the bot is smart enough to update from the updated JBS isssue, and the summary command does not do what I thought. Let me try to fix it.

[caojoshua]

/summary

[openjdk]

@caojoshua Removing existing summary

[caojoshua]

/integrate

[openjdk]

@caojoshua
Your change (at version d221841) is now ready to be sponsored by a Committer.

[TheShermanTanker]

/sponsor

[openjdk]

Going to push as commit 34e66ce.
Since your change was applied there have been 20 commits pushed to the master branch:

• a19b28a: 8297539: Use PrimitiveConversions::cast for local uses of the int<->float union conversion trick
• 8eb4e7e: 8277501: Revisit PathFileObject.getCharContent and friends
• abfb900: 8304028: Port fdlibm IEEEremainder to Java
• a565be4: 8297605: improve DelayQueue removal method javadoc
• cccb019: 8304928: Optimize ClassDesc.resolveConstantDesc
• bdbf8fc: 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value
• 4a5d7ca: 8305227: [s390x] build broken after JDK-8231349
• dae1ab3: 8304844: JFR: Missing disk parameter in ActiveRecording event
• e012685: 8305066: [JVMCI] guarantee(ik->is_initialized()) failed: java/lang/Long$LongCache must be initialized
• fe42312: 8304820: Statically allocate ObjectSynchronizer mutexes
• ... and 10 more: https://git.openjdk.org/jdk/compare/83cf28f99639d80e62c4031c4c9752460de5f36c...master

Your commit was automatically rebased without conflicts.

[openjdk]

@TheShermanTanker @caojoshua Pushed as commit 34e66ce.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.