Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Julian Waters
On Tue, 8 Aug 2023 20:53:19 GMT, Thomas Stuefe wrote: > I think I see now that the added scopes were to prevent variable life scopes > from intersecting goto's? Yes, that's why - PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1670618830

Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Julian Waters
On Tue, 8 Aug 2023 19:56:24 GMT, Thomas Stuefe wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 22 additional >> commits

Re: RFR: 8313374: --enable-ccache's CCACHE_BASEDIR breaks builds [v5]

2023-08-08 Thread Jan Kratochvil
> https://bugs.openjdk.org/browse/JDK-8313374 > --enable-ccache's CCACHE_BASEDIR breaks builds Jan Kratochvil has updated the pull request incrementally with one additional commit since the last revision: Rename NEED_FIX_DEPS_FILE to REWRITE_PATHS_RELATIVE - suggested by Erik Joelsson.

Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Thomas Stuefe
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done >> with some effort, given that the

Re: RFR: JDK-8313244: NM flags handling in configure process [v3]

2023-08-08 Thread Christoph Langer
On Tue, 8 Aug 2023 20:14:55 GMT, Erik Joelsson wrote: > > Looks good overall. I suggest to remove the BUILD_NM variable in this PR as > > well. We should then wait with a final review until some folks from the > > Oracle build team are back. > > What is the motivation for removing BUILD_NM? I

Re: RFR: JDK-8313244: NM flags handling in configure process [v3]

2023-08-08 Thread Erik Joelsson
On Fri, 4 Aug 2023 09:52:30 GMT, Christoph Langer wrote: > Looks good overall. I suggest to remove the BUILD_NM variable in this PR as > well. We should then wait with a final review until some folks from the > Oracle build team are back. What is the motivation for removing BUILD_NM? I

Re: RFR: JDK-8313244: NM flags handling in configure process [v3]

2023-08-08 Thread Erik Joelsson
On Fri, 4 Aug 2023 14:37:04 GMT, Andreas Steiner wrote: >> On AIX we need the -X64 option for NM in the build. The handling is >> equivalent to the other used tools flags like AR. >> This change will replace the quick fix done in >> https://bugs.openjdk.org/browse/JDK-8312466. > > Andreas

Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Thomas Stuefe
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done >> with some effort, given that the

Re: RFR: 8313592: RISC-V: Link libatomic statically

2023-08-08 Thread Ludovic Henry
On Wed, 2 Aug 2023 06:55:40 GMT, Ludovic Henry wrote: > Currently, RISC-V differs from other platforms in that it requires the > linkage to libatomic.so to support sub-word atomic operations. However, > because it is linked dynamically, it will depend on the installation of > libatomic.so on

Withdrawn: 8313592: RISC-V: Link libatomic statically

2023-08-08 Thread Ludovic Henry
On Wed, 2 Aug 2023 06:55:40 GMT, Ludovic Henry wrote: > Currently, RISC-V differs from other platforms in that it requires the > linkage to libatomic.so to support sub-word atomic operations. However, > because it is linked dynamically, it will depend on the installation of > libatomic.so on

Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Thomas Stuefe
On Mon, 7 Aug 2023 08:14:41 GMT, Julian Waters wrote: >> There are currently only 2 possible types of HMODULE and char/uint8_t for T >> at the moment. Weirdly enough only line 126 errors out without the cast >> while line 114, despite having the same problem, doesn't, but I added the >> cast

Re: RFR: 8313374: --enable-ccache's CCACHE_BASEDIR breaks builds [v4]

2023-08-08 Thread Kim Barrett
On Mon, 31 Jul 2023 07:52:42 GMT, Jan Kratochvil wrote: > I doubt there is anyone as it did not work. :-) Um, I've been using it for years without noticing any problems, and measured a frequent speedup for my normal use. - PR Comment:

Re: RFR: 8307160: [REDO] Enable the permissive- flag on the Microsoft Visual C compiler [v2]

2023-08-08 Thread Erik Joelsson
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote: >> We should set the -permissive- flag for the Microsoft Visual C compiler, as >> was requested by the now backed out >> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done >> with some effort, given that the

Re: RFR: 8312522: Implementation of Foreign Function & Memory API

2023-08-08 Thread Erik Joelsson
On Tue, 1 Aug 2023 10:29:06 GMT, Jorn Vernee wrote: > This patch contains the implementation of the foreign linker & memory API JEP > for Java 22. The initial patch is composed of commits brought over directly > from the [panama-foreign repo](https://github.com/openjdk/panama-foreign). > The

Re: RFR: JDK-8312467: relax the builddir check in make/autoconf/basic.m4 [v2]

2023-08-08 Thread Erik Joelsson
On Wed, 26 Jul 2023 07:21:13 GMT, Matthias Baesken wrote: >> In case of issues in the configure step, we run into error messages like >> this : >> >> configure: Current directory is /openjdk/jdk_4/build_mymachine. >> configure: Since this is not the source root, configure will output the >>

Re: RFR: 8311247: Some cpp files are compiled with -std:c11 flag

2023-08-08 Thread Erik Joelsson
On Mon, 3 Jul 2023 17:15:17 GMT, Daniel JeliƄski wrote: > Please review this patch that configures C++ arguments on build jobs that > involve compiling CPP files. As a result of this change, CPP files are > compiled with `-std:c++14` command line argument instead of `-std:c11`, which > is

Re: RFR: 8313374: --enable-ccache's CCACHE_BASEDIR breaks builds [v4]

2023-08-08 Thread Erik Joelsson
On Mon, 31 Jul 2023 07:00:00 GMT, Jan Kratochvil wrote: >> https://bugs.openjdk.org/browse/JDK-8313374 >> --enable-ccache's CCACHE_BASEDIR breaks builds > > Jan Kratochvil has updated the pull request incrementally with one additional > commit since the last revision: > > Adjust

Re: RFR: 8312882: Update the CONTRIBUTING.md with pointers to lifecycle of a PR

2023-08-08 Thread Jesse Glick
On Tue, 8 Aug 2023 12:58:15 GMT, Erik Joelsson wrote: > It would be better to update the text on openjdk.org to reflect the current > practice and processes. In that case shall I close this PR, and someone with permission to do so could reword JDK-8312882 to that effect? - PR

Re: RFR: 8313374: --enable-ccache's CCACHE_BASEDIR breaks builds [v4]

2023-08-08 Thread Jan Kratochvil
On Tue, 8 Aug 2023 13:26:22 GMT, Erik Joelsson wrote: > I understand why you need `fix-deps-file` when using `ccache`, but do you > also need `MakeCommandRelative`? I did try it without `MakeCommandRelative`. But it did not work. As the relative paths created by `ccache` itself will look

Re: RFR: 8313374: --enable-ccache's CCACHE_BASEDIR breaks builds [v4]

2023-08-08 Thread Erik Joelsson
On Mon, 31 Jul 2023 07:00:00 GMT, Jan Kratochvil wrote: >> https://bugs.openjdk.org/browse/JDK-8313374 >> --enable-ccache's CCACHE_BASEDIR breaks builds > > Jan Kratochvil has updated the pull request incrementally with one additional > commit since the last revision: > > Adjust

Re: RFR: 8312882: Update the CONTRIBUTING.md with pointers to lifecycle of a PR

2023-08-08 Thread Erik Joelsson
On Tue, 25 Jul 2023 16:19:27 GMT, Jesse Glick wrote: > By the way the bots seem to contradict themselves: > > > Commit message must refer to an issue > > and a previous failing `jcheck-openjdk/jdk-14716` check run referred to a > _commit_ message. Yet > > > Please do not rebase or force-push