Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 2 commits into from

Conversation

caojoshua
Copy link
Contributor

@caojoshua caojoshua commented Mar 30, 2023

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

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
Copy link

bridgekeeper bot commented Mar 30, 2023

👋 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
Copy link
Contributor Author

caojoshua commented Mar 30, 2023

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

@openjdk openjdk bot added the rfr Pull request is ready for review label Mar 30, 2023
@openjdk
Copy link

openjdk bot commented Mar 30, 2023

@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.

@openjdk openjdk bot added build build-dev@openjdk.org client client-libs-dev@openjdk.org labels Mar 30, 2023
@mlbridge
Copy link

mlbridge bot commented Mar 30, 2023

Webrevs

@mrserb
Copy link
Member

mrserb commented Mar 30, 2023

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
Copy link
Member

erikj79 commented Mar 30, 2023

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
Copy link
Member

mrserb commented Mar 31, 2023

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?

Copy link
Member

@shipilev shipilev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link

openjdk bot commented Mar 31, 2023

@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).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Mar 31, 2023
@shipilev
Copy link
Member

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
Copy link
Member

erikj79 commented Mar 31, 2023

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
Copy link
Member

mrserb commented Mar 31, 2023

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 caojoshua changed the title 8304295: VM build fails with GCC 7 after JDK-8301998 8304295: harfbuzz build fails with GCC 7 after JDK-8301998 Mar 31, 2023
@caojoshua
Copy link
Contributor Author

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

@openjdk
Copy link

openjdk bot commented Mar 31, 2023

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

@caojoshua
Copy link
Contributor Author

caojoshua commented Mar 31, 2023

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
Copy link
Contributor Author

/summary

@openjdk
Copy link

openjdk bot commented Mar 31, 2023

@caojoshua Removing existing summary

@caojoshua
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Mar 31, 2023
@openjdk
Copy link

openjdk bot commented Mar 31, 2023

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

@TheShermanTanker
Copy link
Contributor

/sponsor

@openjdk
Copy link

openjdk bot commented Apr 1, 2023

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 openjdk bot added the integrated Pull request has been integrated label Apr 1, 2023
@openjdk openjdk bot closed this Apr 1, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Apr 1, 2023
@openjdk
Copy link

openjdk bot commented Apr 1, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build build-dev@openjdk.org client client-libs-dev@openjdk.org integrated Pull request has been integrated
5 participants