On Sat, 20 Sep 2025 14:27:21 GMT, SendaoYan wrote:
> Hi, jdk support address sanitizer and leak sanitizer for now. It seems that
> this PR only concern address sanitizer, does the leak sanitizer also need
> this enhancement
gcc15.2 docs list the sanitizers that support recovery, and "leak" is
On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe wrote:
> ASAN, when catching an error, will abort the process.
>
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp.
> `-fno-sanitize-recover=address`. This controls whether, once ASAN returns
> from its error
On Sat, 20 Sep 2025 14:22:16 GMT, SendaoYan wrote:
>> ASAN, when catching an error, will abort the process.
>>
>> Two things control this:
>> 1) the compiler option `-fsanitize-recover=address` (resp.
>> `-fno-sanitize-recover=address`. This controls whether, once ASAN returns
>> from its erro
> Hi all,
>
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report
> compilation failre, shows as
> [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>
> This PR add the expression `svfloat64_t a() {}` to makefile which will
> trigger the compilation during co
On Fri, 12 Sep 2025 06:57:44 GMT, SendaoYan wrote:
>> make/autoconf/flags-other.m4 line 167:
>>
>>> 165: fi
>>> 166: CFLAGS="$OLD_CFLAGS"
>>> 167: AC_LANG_POP(C)
>>
>> This part should be included in the `IF_ENABLED` block in `UTIL_ARG_ENABLE`.
>
> The `FLAGS_COMPILER_CHECK_ARGUMENT
On Wed, 10 Sep 2025 09:38:59 GMT, SendaoYan wrote:
>> Hi all,
>>
>> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report
>> compilation failre, shows as
>> [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>>
>> This PR add the expression `svfloat64_t a() {}`
On Fri, 12 Sep 2025 16:28:00 GMT, Erik Joelsson wrote:
>> Oh, and also, you can extract a common:
>>
>> AC_MSG_RESULT([$AARCH64_SVE_AVAILABLE])
>>
>> after the compile test. This lets you get rid of the else block completely,
>> and it makes it clear that the AC_MSG_CHECKING is always terminat
Can I please get a review of this change which removes the `jrunscript` tool?
This addresses https://bugs.openjdk.org/browse/JDK-8367157.
`jrunscript` is an experimental and unsupported tool which was deprecated for
removal in Java 24. The commits in this PR remove the tool, its man pages and
a
On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote:
> This PR adds a new compiler warning for `@SuppressWarnings` annotations that
> don't actually suppress any warnings.
>
> Summary of code changes:
>
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` t
> Hi everyone, please help review this patch which Implement the
> _counterMode_AESCrypt with Zvkned. On my QEMU, with Zvkned extension enabled,
> the tests in test/hotspot/jtreg/compiler/codegen/aes/ Passed.
Anjian Wen has updated the pull request incrementally with one additional
commit since
On Fri, 19 Sep 2025 07:09:27 GMT, Fei Yang wrote:
>> Anjian Wen 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 eight additional
>> commits sinc
On Wed, 17 Sep 2025 18:57:45 GMT, Magnus Ihse Bursie wrote:
> An alternative implementation to https://github.com/openjdk/jdk/pull/27338,
> which removes the entire gensrc stage and instead permanently checks in the
> generated Java files.
This pull request has now been integrated.
Changeset:
On Thu, 18 Sep 2025 15:58:07 GMT, Alan Bateman wrote:
> Can you confirm that tier1 + tier2 are passing? (most of the tests are in
> tier2).
Yes, they pass with flying colors.
-
PR Comment: https://git.openjdk.org/jdk/pull/27352#issuecomment-3311543989
On Fri, 5 Sep 2025 17:08:30 GMT, Magnus Ihse Bursie wrote:
> We should wrap the call to `mt` in `ExecuteWithLog`. I tried to do this
> earlier but ran into problems with the tricky command line. The solution was
> to use `$$(COMMA)` (and `$$(HASH)`); I'm not sure why I did not see this
> befor
On Wed, 17 Sep 2025 05:20:29 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change to a jtreg failure handler
> command?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8367801, the change in this
> PR removes the use of "-L" option from the "ps" command to reduce the
On Sat, 10 May 2025 20:20:32 GMT, Archie Cobbs wrote:
> This PR adds a new compiler warning for `@SuppressWarnings` annotations that
> don't actually suppress any warnings.
>
> Summary of code changes:
>
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` t
On Thu, 18 Sep 2025 13:13:20 GMT, Erik Joelsson wrote:
> I have started a verification job with tier1-5.
Hi Erik, thanks for checking !
-
PR Comment: https://git.openjdk.org/jdk/pull/27358#issuecomment-3307512079
> Hi all,
>
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report
> compilation failre, shows as
> [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>
> This PR add the expression `svfloat64_t a() {}` to makefile which will
> trigger the compilation during co
On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote:
>> This is a general cleanup and improvement of LTO, as well as a quick fix to
>> remove a workaround in the Makefiles that disabled LTO for
>> g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble.
>> The -Wno-attrib
> Hi all,
>
> Build jdk on linux-aarch64 with older assembler version(as 2.30) will report
> compilation failre, shows as
> [JDK-8366777](https://bugs.openjdk.org/browse/JDK-8366777).
>
> This PR add the expression `svfloat64_t a() {}` to makefile which will
> trigger the compilation during co
On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe wrote:
> ASAN, when catching an error, will abort the process.
>
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp.
> `-fno-sanitize-recover=address`. This controls whether, once ASAN returns
> from its error
On Sat, 20 Sep 2025 07:33:34 GMT, Thomas Stuefe wrote:
> ASAN, when catching an error, will abort the process.
>
> Two things control this:
> 1) the compiler option `-fsanitize-recover=address` (resp.
> `-fno-sanitize-recover=address`. This controls whether, once ASAN returns
> from its error
On Fri, 19 Sep 2025 16:43:50 GMT, Magnus Ihse Bursie wrote:
> We currently have three macros (as in "functions", not just simple strings)
> that are assigned in spec.gmk. This is in contrast with the rest of the
> values assigned in spec.gmk, and it is surprising and is forcing an odd
> syntax
ASAN, when catching an error, will abort the process.
Two things control this:
1) the compiler option `-fsanitize-recover=address` (resp.
`-fno-sanitize-recover=address`. This controls whether, once ASAN returns from
its error report, the compiler-generated ASAN stubs will abort the process.
Th
24 matches
Mail list logo
