VectorGatherMaskFoldingTest fails for s390x and riscv jdk 23

[jiekang]

Logs:

[2024-09-16T17:39:11.476Z] Caused by: java.lang.RuntimeException: assertNotEquals: expected [1] to not equal [1]
[2024-09-16T17:39:11.476Z] 	at jdk.test.lib.Asserts.fail(Asserts.java:691)
[2024-09-16T17:39:11.476Z] 	at jdk.test.lib.Asserts.assertNotEquals(Asserts.java:451)
[2024-09-16T17:39:11.476Z] 	at jdk.test.lib.Asserts.assertNotEquals(Asserts.java:435)
[2024-09-16T17:39:11.476Z] 	at compiler.vectorapi.VectorGatherMaskFoldingTest.testTwoLongVectorLoadGatherMaskedNotEqualMask(VectorGatherMaskFoldingTest.java:227)
[2024-09-16T17:39:11.476Z] 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[2024-09-16T17:39:11.476Z] 	... 7 more

From:
https://ci.adoptium.net/job/Grinder/10882/consoleText

[jiekang]

The test is newly introduced in 23+ via:
https://bugs.openjdk.org/browse/JDK-8325520

The test is known to fail when maximum vector bits is 64:
https://bugs.openjdk.org/browse/JDK-8333248

Though the comment specifically mentions aarch64 and risc-v, it may be that it applies to s390x as well. The test has been fixed but the code was not backported to 23 yet.

[jiekang]

Maybe we can check what the vector bits setting is for s390x and then consider excluding this test.

[jiekang]

Or apply the patch to 23 and run the test. Not sure what will take the least amount of work/effort though...

[jiekang]

Could also try other vendor releases for s390x to see if the test failed

[sophia-guo]

I guess only openj9 support s390x

[Haroon-Khel]

I applied the changes in adoptium/jdk@9b0a5c5 and the test passes on s390x

[jiekang]

I would vote to ignore this test result for the release then.

[smlambert]

Yes, and in fact, excluding this testcase in master using https://bugs.openjdk.org/browse/JDK-8333248 as the link in the ProblemList entry and cherrypick to October's release branch v1.0.4-release would be appropriate.

[jiekang]

I will submit an exclude for the master branch and then coordinate with someone to cherry pick it.

[jiekang]

The test is also failing for the same reason on riscv. Updating this issue to track that and will also add it to the excludes.

[jiekang]

Sorry for missing that in the initial PRs

[jiekang]

This should be fixed in 23.0.2, coming out on 2025-01-21, so the exclusion can be removed after 23.0.1 is released on 2024-10-15.

Wonder if there's a remind me feature I can use for this...

[smlambert]

This was excluded for JDK23 but not for JDK21 where the failure is also now seen, #5690 (comment).

[jiekang]

:|

I've commented on both https://bugs.openjdk.org/browse/JDK-8325520 and https://bugs.openjdk.org/browse/JDK-8333248 so hopefully future backports will include both fixes. It was noted that the original issue was also seen on 17 and 11, so maybe someone will backport that there.

There is an open work item to backport the test-case fix (JDK-8333248) to 21 then if anyone wants to take that on.

For updating AQA excludes, I will submit a PR later today.

[sophia-guo]

@jiehang, I didn't see the https://bugs.openjdk.org/browse/JDK-8325520 was back port to 17 and 11. Can you double check?

I'd love to do the backport JDK-8333248 to 21, but I didn't find the work item opened?

[jiekang]

@sophia-guo Yes JDK-8325520 was not backported to 17 or 11. It was backported to 21 in June though.

For JDK-8333248 to 21, what work item are you looking for? I'm not sure I understood the question. When you follow the backport steps with the PR, it will do a lot of JBS things for you, including managing the backport issue.

[sophia-guo]

openjdk/jdk21u-dev#1100