On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote:
> Build and use SLEEF library as a backend implementation for Vector API
> trigonometric functions on macosx-aarch64 platform.
>
> It improves raw throughput and eliminates GC overhead of non-intrinsified
> Vector API operation.
>
> PR
On Thu, 27 Mar 2025 19:38:28 GMT, Erik Joelsson wrote:
> Wait, are you saying you can get a native build to work by setting
> --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO.
No, it's not. If we could block the `--build` flag, we would. This is the
built-in autoconf tar
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote:
>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
>> triggers 1000+ warning messages like `cc1plus: warning: command-line option
>> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>>
>> T
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote:
>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
>> triggers 1000+ warning messages like `cc1plus: warning: command-line option
>> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>>
>> T
On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan wrote:
> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches
> end of non-void function [-Werror=return-type] with gcc options
> -fsanitize=address -O0. The function int JavaMain(void* _args) in this file
> will exe
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote:
> in this particular case I wonder if not a pragma in the LEAVE macro would be
> better?
I will try it later.
-
PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766150226
On Fri, 28 Mar 2025 05:10:33 GMT, Julian Waters wrote:
> > Wait, sorry to trouble you further, but what does nm --demangle
> > --reverse-sort --print-size --size-sort libjvm.so on HotSpot compiled by
> > gcc 14 with LTO active yield as the largest symbol in the binary? (It
> > should be the sy
On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote:
> The target selection configuration flag for Windows AArch64 should be added
> to the build documentation for improved discoverability and completeness.
But is the problem that we just fails to detect the *build* platform, and thus
genera
On Sat, 22 Mar 2025 10:09:46 GMT, Patrick Zhang wrote:
>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
>> triggers 1000+ warning messages like `cc1plus: warning: command-line option
>> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>>
>> T
On Mon, 31 Mar 2025 12:31:10 GMT, Magnus Ihse Bursie wrote:
> Wait a minute. I re-read the discussion a bit more carefully, and let my
> brain re-process what I said above...
>
> Is the goal here to document how you properly do cross-compilation for
> windows/aarch64 on windows/x64? If so, I t
> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
> triggers 1000+ warning messages like `cc1plus: warning: command-line option
> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>
> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA
On Wed, 26 Mar 2025 22:38:40 GMT, Saint Wesonga wrote:
> The target selection configuration flag for Windows AArch64 should be added
> to the build documentation for improved discoverability and completeness.
> But is the problem that we just fails to detect the _build_ platform, and
> thus ge
> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
> triggers 1000+ warning messages like `cc1plus: warning: command-line option
> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>
> The root cause is that `JVM_CFLAGS ` which contains both `EXTRA
On Mon, 31 Mar 2025 13:35:24 GMT, Magnus Ihse Bursie wrote:
> So in this context, having the proposed comment at that place only just adds
> to the confusion.
Sure, I removed the comments with a new commit.
-
PR Comment: https://git.openjdk.org/jdk/pull/24115#issuecomment-27664413
On Mon, 31 Mar 2025 13:24:25 GMT, Magnus Ihse Bursie wrote:
>>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk` to `-DSTATIC_BUILD=1`, which
>>> was missed by
>>> [cbab40bc](https://github.com/openjdk/jdk/commit/cbab40bce45a2f58906be49c841178fa1dfd457e#diff-ab3ce05e795360030f19402fd0c2fad1dc1f7c5e7
On Mon, 31 Mar 2025 14:27:19 GMT, Erik Joelsson wrote:
> > But is the problem that we just fails to detect the _build_ platform, and
> > thus generates build tools for x64, instead of aarch64, which makes the
> > build fail? (Also, why doesn't the rosetta-equivalent kick in in that case?)
> > O
On Mon, 31 Mar 2025 10:14:54 GMT, Magnus Ihse Bursie wrote:
> > Wait, are you saying you can get a native build to work by setting
> > --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO.
>
> No, it's not. If we could block the `--build` flag, we would. This is the
> built-i
On Thu, 27 Mar 2025 20:48:22 GMT, Naoto Sato wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java
>> line 198:
>>
>>> 196:
>>> 197: if (it.hasNext()) {
>>> 198: out.append("\n\r");
>>
>> I understand this is a simple console, bu
On Thu, 27 Mar 2025 18:28:17 GMT, Naoto Sato wrote:
>> The `java.io.Console` has several backends: a simple on in `java.base`, a
>> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
>> and one for JShell.
>>
>> The backend based on JLine is proving to be a somewhat pr
On Mon, 31 Mar 2025 17:04:55 GMT, Jan Lahoda wrote:
>> src/jdk.internal.le/share/classes/jdk/internal/console/SimpleConsoleReader.java
>> line 69:
>>
>>> 67: case 4: break READ; //EOF/Ctrl-D
>>> 68: case 127:
>>> 69: //backspace:
>>
>> Is it
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote:
> The `java.io.Console` has several backends: a simple on in `java.base`, a
> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
> and one for JShell.
>
> The backend based on JLine is proving to be a somewhat problem
> The target selection configuration flag for Windows AArch64 should be added
> to the build documentation for improved discoverability and completeness.
Saint Wesonga has updated the pull request incrementally with one additional
commit since the last revision:
Add instructions for a native
On Fri, 28 Mar 2025 23:44:19 GMT, Mikael Vidstedt wrote:
> With the JDK 24 GA out it's time to bump the minimum boot JDK version for
> mainline/JDK 25.
>
> Testing: tier1-5, GHA
Marked as reviewed by ihse (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/24305#pullrequest
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote:
> The `java.io.Console` has several backends: a simple on in `java.base`, a
> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
> and one for JShell.
>
> The backend based on JLine is proving to be a somewhat problem
On Wed, 26 Mar 2025 07:54:48 GMT, Jan Lahoda wrote:
> The `java.io.Console` has several backends: a simple on in `java.base`, a
> more convenient one in `jdk.internal.le` (with line-reading based on JLine)
> and one for JShell.
>
> The backend based on JLine is proving to be a somewhat problem
On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote:
> Build and use SLEEF library as a backend implementation for Vector API
> trigonometric functions on macosx-aarch64 platform.
>
> It improves raw throughput and eliminates GC overhead of non-intrinsified
> Vector API operation.
>
> PR
On Tue, 25 Mar 2025 01:54:33 GMT, Patrick Zhang wrote:
>> make/common/native/Flags.gmk line 125:
>>
>>> 123: endif
>>> 124: ifeq ($(STATIC_LIBS), true)
>>> 125: $1_EXTRA_CXXFLAGS += -DSTATIC_BUILD=1
>>
>> This seems unrelated to the fix?
>
>> 3. Fixed `STATIC_LIB_CFLAGS` in `Flags.gmk`
It turns out one instance of STATIC_LIB_CFLAGS was missed in Flags.gmk when
fixing [JDK-8345683](https://bugs.openjdk.org/browse/JDK-8345683). This was
noticed by @cnqpzhang in
https://github.com/openjdk/jdk/pull/24115/files#r2011164138.
-
Commit messages:
- 8353272: One instance
On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote:
> Build and use SLEEF library as a backend implementation for Vector API
> trigonometric functions on macosx-aarch64 platform.
>
> It improves raw throughput and eliminates GC overhead of non-intrinsified
> Vector API operation.
>
> PR
On Sat, 29 Mar 2025 00:58:59 GMT, Vladimir Ivanov wrote:
> Build and use SLEEF library as a backend implementation for Vector API
> trigonometric functions on macosx-aarch64 platform.
>
> It improves raw throughput and eliminates GC overhead of non-intrinsified
> Vector API operation.
>
> PR
On Mon, 31 Mar 2025 14:31:56 GMT, Patrick Zhang wrote:
>> Building jdk with `--with-extra-cflags='-Wno-incompatible-pointer-types'`
>> triggers 1000+ warning messages like `cc1plus: warning: command-line option
>> ‘-Wno-incompatible-pointer-types’ is valid for C/ObjC but not for C++`.
>>
>> T
On Mon, 31 Mar 2025 15:00:08 GMT, Saint Wesonga wrote:
> > > Wait, are you saying you can get a native build to work by setting
> > > --build=aarch64-pc-cygwin? If so, then that's a better instruction IMO.
> >
> >
> > No, it's not. If we could block the `--build` flag, we would. This is the
>
On Mon, 31 Mar 2025 14:44:23 GMT, Saint Wesonga wrote:
> Upon closer inspection, the --build option results in a native build (per the
> build system) but the ARM64 C++ compiler binary (cl.exe) is actually an x64
> binary, so the compiler is running in emulated mode despite the build system
>
On Mon, 31 Mar 2025 13:16:34 GMT, Erik Joelsson wrote:
> > Wait a minute. I re-read the discussion a bit more carefully, and let my
> > brain re-process what I said above...
> > Is the goal here to document how you properly do cross-compilation for
> > windows/aarch64 on windows/x64? If so, I t
34 matches
Mail list logo
