On Wed, 30 Jul 2025 16:26:55 GMT, Jaikiran Pai wrote:
> Hello Hao,
>
> > Hi, I encountered two jtreg failures with this new version `8` on both
> > AArch64 and x86_64 platforms.
> > Note that these two jtreg cases can pass with jtreg `7.5.2+1` version.
>
> Thank you for bringing this up. I'm a
On Fri, 11 Jul 2025 09:05:40 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 8.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the requiredVersion h
On Thu, 9 Nov 2023 16:07:53 GMT, Mikael Vidstedt wrote:
> This PR is splitting out the GCC 13.2.0 warning related changes from #16550,
> excluding the Oracle/devkit parts, for clarity and to make potential
> backports more straightforward.
>
> GCC 13.2.0 generates two new warnings:
>
> * linu
On Tue, 7 Nov 2023 23:37:06 GMT, Mikael Vidstedt wrote:
> Oracle is updating the version of GCC for building the JDK on Linux to 13.2.0.
>
> Apart from the "obvious" changes, I'll add some color to the CompileJvm.gmk
> changes. In particular, I ran into two different types of new warnings with
On Tue, 7 Nov 2023 23:37:06 GMT, Mikael Vidstedt wrote:
> Oracle is updating the version of GCC for building the JDK on Linux to 13.2.0.
>
> Apart from the "obvious" changes, I'll add some color to the CompileJvm.gmk
> changes. In particular, I ran into two different types of new warnings with
On Mon, 6 Feb 2023 11:50:57 GMT, Doug Simon wrote:
>> Thanks for reporting this. @dougxc
>>
>> Yes. I encountered several jtreg failures with Graal, which is built with
>> PAC-RET enabled JDK.
>>
>> As I see it, the straightforward fix is to disable JVMCI if
>> `_rop_protection` is parsed as
On Tue, 31 Jan 2023 14:59:31 GMT, Doug Simon wrote:
>> Alan Hayward has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 34 commits:
>>
>> - Merge master
>> - Merge master
>> - Merge master
>> - Error on -XX:-PreserveFramePointer -
On Wed, 28 Sep 2022 07:38:56 GMT, Magnus Ihse Bursie wrote:
>> make/hotspot/lib/CompileJvm.gmk line 160:
>>
>>> 158: DISABLED_WARNINGS_gcc_javaClasses.cpp := misleading-indentation, \
>>> 159: DISABLED_WARNINGS_gcc_loopnode.cpp := sequence-point, \
>>> 160: DISABLED_WARNINGS_gcc_post
On Tue, 27 Sep 2022 16:51:21 GMT, Magnus Ihse Bursie wrote:
>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now
>> possible to disable warnings for individual files instead for whole
>> libraries. I used this opportunity to go through all disabled warnings in
>> hots
On Tue, 27 Sep 2022 16:51:21 GMT, Magnus Ihse Bursie wrote:
>> After [JDK-8294281](https://bugs.openjdk.org/browse/JDK-8294281), it is now
>> possible to disable warnings for individual files instead for whole
>> libraries. I used this opportunity to go through all disabled warnings in
>> hots
On Thu, 22 Sep 2022 07:02:16 GMT, Hao Sun wrote:
> This warning seems to be a false positive, because 1) array "fq" with
> elements from index 0 to "jz" has already been initialized as "fw" at line
> 290 [1], and 2) variable "jz" should
On Mon, 26 Sep 2022 01:39:41 GMT, Hao Sun wrote:
>> This warning seems to be a false positive, because 1) array "fq" with
>> elements from index 0 to "jz" has already been initialized as "fw" at line
>> 290 [1], and 2) variable "jz"
On Fri, 23 Sep 2022 12:47:24 GMT, Magnus Ihse Bursie wrote:
>> Thanks for your review.
>>
>> Your mentioned solution should work and we can also enable the pragma only
>> for aarch64 + gcc>=12 condition.
>> I considered such a solution when preparing this patch.
>>
>> But I personally prefer t
s://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L290
>
> [2]
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libfdlibm/k_rem_pio2.c#L99
>
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106992
Hao Sun has updated the p
On Fri, 23 Sep 2022 13:22:08 GMT, Erik Joelsson wrote:
> I think this looks good, but could you provide an example of how this would
> be used in the bug?
Hi, https://github.com/openjdk/jdk/pull/10414 shows an example.
-
PR: https://git.openjdk.org/jdk/pull/10408
On Thu, 22 Sep 2022 09:35:47 GMT, Andrew Haley wrote:
>> This warning seems to be a false positive, because 1) array "fq" with
>> elements from index 0 to "jz" has already been initialized as "fw" at line
>> 290 [1], and 2) variable "jz" should be non-negative from the comment at
>> line 99 [2
This warning seems to be a false positive, because 1) array "fq" with elements
from index 0 to "jz" has already been initialized as "fw" at line 290 [1], and
2) variable "jz" should be non-negative from the comment at line 99 [2].
Note-1: GCC warning option -Wmaybe-uninitialized is not a new one
On Mon, 4 Jul 2022 12:51:22 GMT, Andrew Haley wrote:
> However, just putting aside for a moment the lack of useful abstraction
> mechanisms, I note that there's a lot of code like this:
>
> ```
> if (length_in_bytes <= 16) {
> // ... Neon
> } else {
> assert(UseSVE > 0, "mus
we choose vector micro-benchmarks from
>> panama-vector:vectorIntrinsics [2] to evaluate the performance of this
>> patch. We've tested *MaxVectorTests.java cases on one 128-bit SVE
>> platform and one NEON platform, and didn't see any visiable regression
>> with NEO
On Fri, 1 Jul 2022 10:36:36 GMT, Hao Sun wrote:
> **MOTIVATION**
>
> This is a big refactoring patch of merging rules in aarch64_sve.ad and
> aarch64_neon.ad. The motivation can also be found at [1].
>
> Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE
**MOTIVATION**
This is a big refactoring patch of merging rules in aarch64_sve.ad and
aarch64_neon.ad. The motivation can also be found at [1].
Currently AArch64 has aarch64_sve.ad and aarch64_neon.ad to support SVE
and NEON codegen respectively. 1) For SVE rules we use vReg operand to
match VecA
21 matches
Mail list logo
