Integrated: 8329672: Only call SetupNativeCompilation from SetupJdkNativeCompilation

2024-04-05 Thread Magnus Ihse Bursie
On Thu, 4 Apr 2024 16:02:53 GMT, Magnus Ihse Bursie wrote: > This patch will fix the few remaining places where a "raw" call to > SetupNativeCompilation was made, instead of going via > SetupJdkNativeCompilation. This include repairing the poor old X11Wrapper, > which has been broken for some

Integrated: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler

2024-04-05 Thread Magnus Ihse Bursie
On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie wrote: > This is a retake on https://github.com/openjdk/jdk/pull/15096. > > I tried to fix the remaining issues in that PR, but could not push them. In > the end, it seemed easier to create a new branch in my own personal fork. > > The majori

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

2024-04-05 Thread Severin Gehwolf
On Thu, 4 Apr 2024 20:56:02 GMT, Magnus Ihse Bursie wrote: >> I was not aware of such a convention and I can't say I agree with it. It >> just seems redundant and unnecessary, but I suppose we should wait for >> Magnus to respond. > > Just to clarify: I did not say the name needed to be long, j

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

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 05:48:40 GMT, Julian Waters wrote: >> Magnus Ihse Bursie 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 two >> additional co

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v2]

2024-04-05 Thread Jatin Bhateja
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256 >

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

2024-04-05 Thread Severin Gehwolf
On Fri, 5 Apr 2024 09:25:49 GMT, Magnus Ihse Bursie wrote: >> Thanks. Yes, the long name was my doing. Sorry. > > Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän" > prejudice of German. ;-) > > > > (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone)

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

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 08:21:09 GMT, Severin Gehwolf wrote: >> Just to clarify: I did not say the name needed to be long, just that many >> (if not all) tools has used the convention of using the package name >> `build.tools.` and the class name `.java`. >> >> I think the new name sounds 👍 . > >

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v3]

2024-04-05 Thread Robbin Ehn
> Hi, please consider. > > [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols. > Tested with gcc and clang, and llvm and binutils backend. > > I didn't find any use of the "DLL_ENTRY", so I removed it. > > Thanks, Robbin Robbin Ehn has updated the pull request incremental

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v2]

2024-04-05 Thread Robbin Ehn
On Thu, 21 Mar 2024 06:58:43 GMT, Robbin Ehn wrote: >> Hi, please consider. >> >> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols. >> Tested with gcc and clang, and llvm and binutils backend. >> >> I didn't find any use of the "DLL_ENTRY", so I removed it. >> >> Thank

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

2024-04-05 Thread Andrew Dinn
On Fri, 5 Apr 2024 09:31:18 GMT, Severin Gehwolf wrote: >> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän" >> prejudice of German. ;-) >> >> >> >> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone) > > Hah! My kids just recently informed me about >

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

2024-04-05 Thread Hamlin Li
> Hi, > Can you help to review the patch? > This pr is based on previous work and discussion in [pr > 16234](https://github.com/openjdk/jdk/pull/16234), [pr > 18294](https://github.com/openjdk/jdk/pull/18294). > > Compared with previous prs, the major change in this pr is to integrate the > sou

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

2024-04-05 Thread Hamlin Li
On Thu, 4 Apr 2024 16:47:44 GMT, Magnus Ihse Bursie wrote: > Build libsleef using their cmake system and look at the compile command line. > (You do this by `VERBOSE=1 cmake` IIRC). Then you can see what flags they are > using. This is what I was referring to as "normal libsleef build". I notic

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

2024-04-05 Thread Hamlin Li
On Thu, 4 Apr 2024 21:55:54 GMT, Mikael Vidstedt wrote: >> Hamlin Li has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - disable unused-function warnings; add log msg >> - minor > > make/modules/jdk.incubator.vector/Lib.gmk line 44: > >>

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v3]

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 10:45:24 GMT, Robbin Ehn wrote: >> Hi, please consider. >> >> [8327045](https://bugs.openjdk.org/browse/JDK-8327045) hide these symbols. >> Tested with gcc and clang, and llvm and binutils backend. >> >> I didn't find any use of the "DLL_ENTRY", so I removed it. >> >> Thanks

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v2]

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 10:42:31 GMT, Robbin Ehn wrote: > Since windows build seems to need HSDIS_TOOLCHAIN_DEFAULT_CFLAGS Rght. That is since we use a completely different compiler, gcc instead of cl. (Which is probably the worst hack in all of the JDK build system...) - PR Commen

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v2]

2024-04-05 Thread Julian Waters
On Fri, 5 Apr 2024 12:43:30 GMT, Magnus Ihse Bursie wrote: > > Since windows build seems to need HSDIS_TOOLCHAIN_DEFAULT_CFLAGS > > Rght. That is since we use a completely different compiler, gcc instead > of cl. (Which is probably the worst hack in all of the JDK build system...) I plan o

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 09:56:48 GMT, Magnus Ihse Bursie wrote: > This is the pinnacle of the recent stream of refactorings in the build > system. This patch introduces a more abstract concept of "JDK_LIBS", where > only the library name (e.g. "java" or "java.desktop:jawt") is specified, and > the

RFR: 8329704: Implement framework for proper handling of JDK_LIBS

2024-04-05 Thread Magnus Ihse Bursie
This is the pinnacle of the recent stream of refactorings in the build system. This patch introduces a more abstract concept of "JDK_LIBS", where only the library name (e.g. "java" or "java.desktop:jawt") is specified, and the build system turns this into suitable linker flags: `-ljawt -L` or `

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v2]

2024-04-05 Thread Magnus Ihse Bursie
> This is the pinnacle of the recent stream of refactorings in the build > system. This patch introduces a more abstract concept of "JDK_LIBS", where > only the library name (e.g. "java" or "java.desktop:jawt") is specified, and > the build system turns this into suitable linker flags: `-ljawt -

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v2]

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 14:14:35 GMT, Magnus Ihse Bursie wrote: >> This is the pinnacle of the recent stream of refactorings in the build >> system. This patch introduces a more abstract concept of "JDK_LIBS", where >> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and >>

Re: RFR: 8328614: hsdis: dlsym can't find decode symbol [v2]

2024-04-05 Thread Magnus Ihse Bursie
On Fri, 5 Apr 2024 14:01:29 GMT, Julian Waters wrote: > I plan on adding support for using gcc to compile hsdis on Windows sometime > soon (Like proper support for gcc as a toolchain on Windows, at least enough > to support hsdis, so people can freely use any gcc instead of only being > restri

Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v2]

2024-04-05 Thread Volodymyr Paprotski
On Tue, 2 Apr 2024 19:19:59 GMT, Volodymyr Paprotski wrote: >> Performance. Before: >> >> Benchmark(algorithm) (dataSize) (keyLength) >> (provider) Mode Cnt ScoreError Units >> SignatureBench.ECDSA.signSHA256withECDSA1024 256 >

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS [v2]

2024-04-05 Thread Erik Joelsson
On Fri, 5 Apr 2024 14:14:35 GMT, Magnus Ihse Bursie wrote: >> This is the pinnacle of the recent stream of refactorings in the build >> system. This patch introduces a more abstract concept of "JDK_LIBS", where >> only the library name (e.g. "java" or "java.desktop:jawt") is specified, and >>

Re: RFR: 8329704: Implement framework for proper handling of JDK_LIBS

2024-04-05 Thread Erik Joelsson
On Fri, 5 Apr 2024 10:11:02 GMT, Magnus Ihse Bursie wrote: > The syntax for specifying JDK libraries can of course be discussed. I tried > to align it with the current syntax for specifying source code, but it does > not match 100%. The differences are: > > * For source code, the default modul