Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v50]

2024-03-19 Thread Julian Waters
On Mon, 18 Mar 2024 15:55:15 GMT, Magnus Ihse Bursie wrote: > bot-keep-alive > > @TheShermanTanker Did you understand the remaining changes that Phil has > requested? Do you think you'll be able to fix this? Hi Magnus, yes I do plan on fixing this. I've just been a bit busy and tired is all,

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46]

2024-03-19 Thread Julian Waters
On Wed, 20 Mar 2024 06:22:50 GMT, Julian Waters wrote: >> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6366: >> >>> 6364: jobject parent = data->parentComp; >>> 6365: >>> 6366: AwtComponent *awtComponent = nullptr; >> >> Looking at it (not tested) here

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v52]

2024-03-19 Thread Julian Waters
> 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). Doing so makes > the Visual C compiler much less accepting of ill formed code, which will > improve code quality on W

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v51]

2024-03-19 Thread Julian Waters
> 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). Doing so makes > the Visual C compiler much less accepting of ill formed code, which will > improve code quality on W

Re: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler [v46]

2024-03-19 Thread Julian Waters
On Sat, 20 Jan 2024 00:17:02 GMT, Phil Race wrote: >> Julian Waters has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 79 commits: >> >> - Merge branch 'openjdk:master' into patch-10 >> - Merge branch 'openjdk:master' into patch-10

Re: RFR: 8314488: Compile the JDK as C++17 [v7]

2024-03-19 Thread Julian Waters
> Compile the JDK as C++17, enabling the use of all C++17 language features Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into patch-7 - Require clang 13 in toolchain.m4 - Remove

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]

2024-03-19 Thread Mandy Chung
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >>

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]

2024-03-19 Thread Andrew Haley
On Tue, 19 Mar 2024 17:00:48 GMT, Hamlin Li wrote: > > The problem I see is that J. Random Java User has no way to know if SLEEF > > is making their program faster without running benchmarks. They'll put > > SLEEF somewhere and hope that Java uses it. > > Please kindly correct me if I misunder

Re: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4]

2024-03-19 Thread Hamlin Li
On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks >> >> This is a continuation of work based on [1] by @XiaohongGong, most work was >> done in that pr. In this new pr, just rebased the code in [1], then added >> some minor changes (renami

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v23]

2024-03-19 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v22]

2024-03-19 Thread Severin Gehwolf
> Please review this patch which adds a jlink mode to the JDK which doesn't > need the packaged modules being present. A.k.a run-time image based jlink. > Fundamentally this patch adds an option to use `jlink` even though your JDK > install might not come with the packaged modules (directory `jm

Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v21]

2024-03-19 Thread Severin Gehwolf
On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung wrote: > This is what I understand from your implementation: > > 1. create a regular JDK image under > `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK > build > > 2. create a linkable JDK image under `images/jdk