On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Fri, 5 Apr 2024 09:17:18 GMT, Jatin Bhateja wrote:
> Few early comments.
>
> Please update the copyright year of all the modified files.
>
> You can even consider splitting this into two patches, Java side changes in
> one and x86 optimized intrinsic in next one.
Thanks Jatin, will fix!
On Fri, 5 Apr 2024 12:17:17 GMT, Hamlin Li wrote:
>> 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
On Wed, 10 Apr 2024 22:12:42 GMT, Kim Barrett wrote:
>> I can live with either, too.
>
> That build failure in shared code does not happen with Xcode clang, gcc, or
> Visual Studio, even though none of them appear to have a relevant define or
> include. So the clang variant being used for AIX is
On Wed, 10 Apr 2024 14:19:59 GMT, Thomas Stuefe wrote:
>> When only looking at AIX code, I think the inclusion of alloca.h was
>> cleaner. Agreed. The new code makes AIX behave like other platforms and
>> avoids the AIX specific part in shared code.
>> I could live with either version.
>
> I
> 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
On Mon, 8 Apr 2024 23:19:13 GMT, Phil Race wrote:
>> The fix provides ability to print Black & White pages on macOS.
>>
>> Cocoa API has
>> [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode)
>> function but it is marked as
On Wed, 10 Apr 2024 09:24:09 GMT, Hamlin Li wrote:
> > Thank you for the update and for working on this in general.
> > I've started working on JDK-8329816, preparing the change for the SLEEF
> > specific part of the change. Specifically, I'm currently planning on
> > including the three SLEEF
On Wed, 10 Apr 2024 14:43:26 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
On Wed, 10 Apr 2024 17:18:55 GMT, Anthony Scarpino
wrote:
> In `ECOperations.java`, if I understand this correctly, it is to replace the
> existing `PointMultiplier` with montgomery-based PointMuliplier. But when I
> look at the code, I see both are still options. If I read this correctly, it
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
On Wed, 10 Apr 2024 14:43:26 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
> 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
> 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
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Wed, 10 Apr 2024 13:46:11 GMT, Martin Doerr wrote:
>> In my humble opinion the inclusion of alloca.h was slightly cleaner, but I
>> guess it doesn't matter. Out of curiosity, why do you guys prefer not
>> including it?
>
> When only looking at AIX code, I think the inclusion of alloca.h was
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Wed, 10 Apr 2024 13:51:30 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
On Tue, 9 Apr 2024 19:43:27 GMT, Erik Joelsson wrote:
> Since we are now able to update the autoconf build-aux files, I think it's
> prudent to semi regularly do just that. I'm not aware of any particular
> platform that has been improved that would affect OpenJDK and I don't think
> we can
> 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
On Wed, 10 Apr 2024 13:41:53 GMT, Magnus Ihse Bursie wrote:
>> make/common/JdkNativeCompilation.gmk line 206:
>>
>>> 204: $$(eval $$(call ResolveLibPath,$1,$2))
>>> 205:
>>> 206: $1_EXTRA_HEADER_DIRS += $$($1_$2_MODULE):lib$$($1_$2_NAME)
>>
>> I think the top level comment need to be
On Wed, 10 Apr 2024 13:35:39 GMT, Julian Waters wrote:
>> Yes I believe. I will remove the `#pragma alloca` everywhere, I will remove
>> the `#include ` everywhere and I will add
>> `-Dalloca=__builtin_alloca` to the compile commands. If it works I will
>> update the PR.
>
> In my humble
On Fri, 5 Apr 2024 18:32:54 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix libfallbackLinker
>
> make/common/JdkNativeCompilation.gmk line 206:
>
>> 204: $$(eval $$(call
> 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
> 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
On Wed, 10 Apr 2024 10:13:37 GMT, Joachim Kern wrote:
>> Can `-Dalloca=__builtin_alloca` replace `#include `?
>
> Yes I believe. I will remove the `#pragma alloca` everywhere, I will remove
> the `#include ` everywhere and I will add
> `-Dalloca=__builtin_alloca` to the compile commands. If
On Wed, 10 Apr 2024 13:19:50 GMT, Martin Doerr wrote:
>> Currently XLC16 but looking to upgrade to XLC17 on the minimum supported
>> level for it (So it wouldn't be SP7 at present). Thanks for the ping - we
>> have no current plans to increase to SP7.
>
> Seems like we need to keep it. This is
On Tue, 9 Apr 2024 17:25:04 GMT, Stewart X Addison wrote:
>> Pinging @sxa - what build environment does temurin use for AIX?
>
> Currently XLC16 but looking to upgrade to XLC17 on the minimum supported
> level for it (So it wouldn't be SP7 at present). Thanks for the ping - we
> have no
On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeliński wrote:
> The "Connection attempt failed: Connection refused" error may happen if the
> client tries to connect to a server that is no longer listening, which in
> turn may happen if the server shuts down without removing the port file. I
>
On Thu, 4 Apr 2024 16:46:32 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
>>
The "Connection attempt failed: Connection refused" error may happen if the
client tries to connect to a server that is no longer listening, which in turn
may happen if the server shuts down without removing the port file. I added a
check that the delete operation succeeded, and retry as
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
On Wed, 10 Apr 2024 10:07:02 GMT, Martin Doerr wrote:
>> Is the comment in front of
>> https://github.com/openjdk/jdk/blob/51ed69a586105b707ae616f9eba898449bf9fba7/src/hotspot/os/aix/os_aix.cpp#L28
>> still correct? Seems like it should get replaced. See
>>
On Wed, 10 Apr 2024 10:00:02 GMT, Martin Doerr wrote:
>> If I omit this #include
>> I get compiler errors of the following kind
>>
>> .../src/hotspot/share/runtime/javaThread.cpp::24: error: use of
>> undeclared identifier 'alloca'
>> char* p1 = (char*) alloca(1);
>>
On Wed, 10 Apr 2024 09:40:16 GMT, Joachim Kern wrote:
>> Do we even need to include ?
>>
>> From the Linux man page for alloca:
>>
>> By necessity, alloca() is a compiler built-in, also known as
>> __builtin_alloca(). By default, modern compilers automatically
>> translate all uses of
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the old xlc toolchain was removed by
>
On Wed, 10 Apr 2024 09:24:09 GMT, Hamlin Li wrote:
> With that in mind, it looks like we could potentially use SLEEF for other
> architectures on linux in the future? And potentially additional operating
> systems as well?
Hi Mikael(@vidmik ) ! :)
Thanks for looking into the legal stuff!
We
On Wed, 10 Apr 2024 00:51:22 GMT, Kim Barrett wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 36:
>>
>>> 34: #if defined(_AIX)
>>> 35: #include
>>> 36: #endif
>>
>> I would much rather see this include added in the few places it was actually
>> needed, rather than being
On Tue, 9 Apr 2024 18:32:04 GMT, Kim Barrett wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> version check not needed anymore
>
> src/hotspot/share/utilities/byteswap.hpp line 2:
>
>> 1: /*
>> 2: * Copyright (c)
On Tue, 9 Apr 2024 20:10:36 GMT, Mikael Vidstedt wrote:
> Thank you for the update and for working on this in general.
>
> I've started working on JDK-8329816, preparing the change for the SLEEF
> specific part of the change. Specifically, I'm currently planning on
> including the three SLEEF
On Tue, 9 Apr 2024 17:00:56 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> version check not needed anymore
>
> src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp line 440:
>
>> 438: st->print("pc ="
On Tue, 9 Apr 2024 16:59:39 GMT, Thomas Stuefe wrote:
>> Hi Thomas, `maxDisclaimSize` is of type `unsigned int`; therefore I get the
>> following warning:
>>
>> os/aix/os_aix.cpp:314:42: error: format specifies type 'unsigned long' but
>> the argument has type 'unsigned int'
44 matches
Mail list logo
