8365570: C2 fails assert(false) failed: Unexpected node in SuperWord truncation: CastII by jaskarth · Pull Request #26827 · openjdk/jdk

jaskarth · 2025-08-18T16:34:52Z

Hi all,
This is a quick patch for the assert failure in superword truncation with CastII. I've added a check for all constraint cast nodes, and attached a reduced version of the fuzzer test. Thanks!

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8365570: C2 fails assert(false) failed: Unexpected node in SuperWord truncation: CastII (Bug - P3)(⚠️ The fixVersion in this issue is [26] but the fixVersion in .jcheck/conf is 27, a new backport will be created when this pr is integrated.)

Reviewers

Emanuel Peter (@eme64 - Reviewer) Review applies to 50bc1326
Christian Hagedorn (@chhagedorn - Reviewer)
Tobias Hartmann (@TobiHartmann - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26827/head:pull/26827
$ git checkout pull/26827

Update a local copy of the PR:
$ git checkout pull/26827
$ git pull https://git.openjdk.org/jdk.git pull/26827/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26827

View PR using the GUI difftool:
$ git pr show -t 26827

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26827.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-08-18T16:35:31Z

👋 Welcome back jkarthikeyan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-08-18T16:38:24Z

@jaskarth This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8365570: C2 fails assert(false) failed: Unexpected node in SuperWord truncation: CastII

Reviewed-by: chagedorn, thartmann, epeter

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 26 new commits pushed to the master branch:

c5159fc: 8374328: Convert simple AtomicAccess uses in gc/shared to use Atomic
904ba5f: 8374718: Generation of CompilerProperties can fail in subtle ways
067fd3c: 8374768: S390X builds are failing after JDK-8372754
... and 23 more: https://git.openjdk.org/jdk/compare/7c979c148724ab7de650593caa22df8405d740e5...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-08-18T16:39:43Z

@jaskarth The following label will be automatically applied to this pull request:

hotspot-compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-08-18T16:43:21Z

Webrevs

eme64 · 2025-08-20T12:53:12Z

src/hotspot/share/opto/superword.cpp

-  // Vector nodes should not truncate.
-  if (type->isa_vect() != nullptr || type->isa_vectmask() != nullptr || in->is_Reduction()) {
+  // Vector nodes and casts should not truncate.
+  if (type->isa_vect() != nullptr || type->isa_vectmask() != nullptr || in->is_Reduction() || in->is_ConstraintCast()) {


Why should we not truncate a CastII? What can go wrong?

My thinking was that since casts specifically change the type of a node, they may not be safe to truncate. In practice it might not matter because after the CastII pack is created, it's discarded because there is no backend implementation for vectorized CastII. I've opted to mark them as non-truncating to stay on the safer side.

I see. Ok. Can you add a comment to the code for that?
Because imagine we come along later and actually implement a backend vectorized version of CastII (no-op?). Maybe because we implement if-conversion. Then it would be nice to know if this was just a "to be on the safe side" check, or if it would run into issues when removed.

Because the current comment says "should not truncate". That sounds more strong than "to be on the safe side".

I think this is fair, I've pushed a commit that changes the comment wording. Let me know what you think!

We have CastVV which should be the packed version of CastII. The thing that is I think the most difficult is to properly wire it. In the simplest situation of all elements in the pack having the same control input can be easily handled, though.

Right. I don't think there is currently any case where CastII would actually be useful to pack in superword. They usually originate from some control-flow. For example a comparison on a variable if (x < 5) and then we can CastII the variable x on the branches. But that only becomes relevant with if-conversion.

Or do you see a case that could happen without if-conversion where CastII needs to be handled?

eme64 · 2025-08-22T06:20:43Z

@jaskarth Thanks for the fix, it looks good to me now :)
I'm just running some internal testing now, please ping me after the weekend :)

eme64

Testing passed 🟢

jaskarth · 2025-08-25T15:24:48Z

Thanks a lot for the testing @eme64! I think I need another review to merge it.

chhagedorn

The fix looks good to me, too! I only have one comment about the test.

chhagedorn · 2025-09-16T07:47:50Z

test/hotspot/jtreg/compiler/vectorization/TestSubwordTruncation.java

        return new Object[] { in, res };
    }

+    @Test(compLevel = CompLevel.C2)


Any particular reason you've chosen C2 here and not let the IR framework handle it? (by default it's ANY which will compile at the highest available tier). I'm also wondering if this test would fail if someone ran the test with a build without C2.

Thanks for the comment! I used CompLevel.C2 here to simulate an -Xcomp environment, since unfortunately I couldn't replicate the crash without it with the IR framework. I'll do some investigation to find a way to ensure that it won't fail without C2.

When you specify @Warmup(0), the IR framework should directly compile it at the highest level which should be C2 if you are not running with a client build. So, I would have expected that it makes no difference. Can you double-check if you can reproduce it with CompLevel.C2 but not without?

After taking a closer look, I think you're correct- I can reproduce the crash using just @Warmup(0) and @Test. I think I used both while debugging and didn't test whether it worked without CompLevel.C2. I've removed it in the latest commit.
However, I noticed that after that I merged from master neither the test nor the reproducer failed compilation before the fix is added. I think another commit must have changed the generated graph so that it no longer tries to vectorize the CastII, leading to the crash not being triggered. I looked at the JBS entry and saw that there wasn't another reproducer for this, so I was a bit unsure on what to do. Should this patch be merged with the current test?

@jaskarth Thanks for looking into it!

I would still add the fix, just in case. And I think the test as well, even if it does not reproduce any more.

I was wondering: before the merge, when the test still reproduced:
If you removed the @Warmup(0) and CompLevel.C2, and instead just do framework.addFlags with -Xcomp, would that reproduce too? If so, you could have a framework run with and one without Xcomp, the one with Xcomp also should have a compileonly. What do you think?

Or we just push the patch as is, to be sure this is done and integrated. What do you think @chhagedorn ?

Yep, I can replicate the crash on the old commit with TestFramework.runWithFlags("-Xcomp", "-XX:CompileCommand=compileonly,*TestSubwordTruncation::*"); instead of @Warmup(0). I think this would also be a good option, as it would let you get coverage with Xcomp on the other tests as well.

I've pushed a commit that changes the Warmup(0) to the second test run.

Given the timeout reported by Tobias, I would rather opt for @Warmup(0) with one run() only. We will eventually run the test with -Xcomp on higher tiers, for example at tier6, so we get Xcomp coverage at some point.

I think that's a good point, I've reverted this change.

bridgekeeper · 2025-10-20T18:11:43Z

@jaskarth This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

bridgekeeper · 2025-11-17T23:40:54Z

@jaskarth This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

TobiHartmann · 2025-11-25T16:03:23Z

Hi @jaskarth: Any plans to pick this back up? Thanks!

jaskarth · 2025-11-25T16:47:28Z

Hi @TobiHartmann, I haven't had a chance to take a look at this due to being busy with my studies but I'm hoping to pick it back up in a week.

jaskarth · 2025-11-25T16:47:34Z

/open

openjdk · 2025-11-25T16:47:41Z

@jaskarth This pull request is now open

TobiHartmann · 2025-11-28T08:46:37Z

Sounds good, thanks for the update!

bridgekeeper · 2026-01-04T04:59:10Z

@jaskarth This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jaskarth · 2026-01-06T23:49:17Z

@TobiHartmann @chhagedorn May I have some reviews on the updated patch? Thank you!

chhagedorn

Update looks good! Thanks for coming back to this.

TobiHartmann

Looks good to me too, thanks! I re-submitted some quick testing and will report back once it passed.

TobiHartmann · 2026-01-07T10:14:05Z

I see timeouts with the test in various configurations, maybe the default timeout should be increased?

compiler.lib.ir_framework.driver.TestVMException: There were one or multiple errors. Please check stderr for more information.
	at compiler.lib.ir_framework.driver.TestVMProcess.throwTestVMException(TestVMProcess.java:251)
	at compiler.lib.ir_framework.driver.TestVMProcess.checkTestVMExitCode(TestVMProcess.java:232)
	at compiler.lib.ir_framework.driver.TestVMProcess.<init>(TestVMProcess.java:77)
	at compiler.lib.ir_framework.TestFramework.runTestVM(TestFramework.java:879)
	at compiler.lib.ir_framework.TestFramework.start(TestFramework.java:839)
	at compiler.lib.ir_framework.TestFramework.start(TestFramework.java:431)
	at compiler.lib.ir_framework.TestFramework.runWithFlags(TestFramework.java:257)
	at compiler.vectorization.TestSubwordTruncation.main(TestSubwordTruncation.java:509)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:335)
	at java.base/java.lang.Thread.run(Thread.java:1516)

JavaTest Message: Test threw exception: compiler.lib.ir_framework.driver.TestVMException
JavaTest Message: shutting down test

result: Error. "driver" action timed out with a timeout of 480 seconds on agent 136; but completed after timeout - suppressed status: "Failed. `main' threw exception: compiler.lib.ir_framework.driver.TestVMException: There were one or multiple errors. Please check stderr for more information."


test result: Error. "driver" action timed out with a timeout of 480 seconds on agent 136; but completed after timeout - suppressed status: "Failed. `main' threw exception: compiler.lib.ir_framework.driver.TestVMException: There were one or multiple errors. Please check stderr for more information."

This reverts commit 50bc132.

jaskarth · 2026-01-08T03:59:45Z

Thank you for running testing @TobiHartmann! I've pushed a commit that reverts the change made to run with -Xcomp directly, so hopefully the timeout is prevented.

TobiHartmann · 2026-01-08T07:01:36Z

Sounds good, I re-submitted testing.

chhagedorn

Looks good, thanks for the update! Let's wait for the testing to be completed.

TobiHartmann · 2026-01-08T11:25:18Z

All tests passed.

jaskarth · 2026-01-09T05:15:48Z

Thank you for the review and testing!

/integrate

openjdk · 2026-01-09T05:16:32Z

Going to push as commit 775f48d.
Since your change was applied there have been 42 commits pushed to the master branch:

9932c78: 8374749: Clarify AnnotationValue specification
368de9f: 8374721: containers/docker/ShareTmpDir.java timed out after 8362087
385c4f8: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC
... and 39 more: https://git.openjdk.org/jdk/compare/7c979c148724ab7de650593caa22df8405d740e5...master

Your commit was automatically rebased without conflicts.

openjdk · 2026-01-09T05:16:41Z

@jaskarth Pushed as commit 775f48d.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

TobiHartmann · 2026-01-09T08:36:25Z

/backport :jdk26

openjdk · 2026-01-09T08:39:00Z

@TobiHartmann the backport was successfully created on the branch backport-TobiHartmann-775f48de-jdk26 in my personal fork of openjdk/jdk. To create a pull request with this backport targeting openjdk/jdk:jdk26, just click the following link:

➡️ Create pull request

The title of the pull request is automatically filled in correctly and below you find a suggestion for the pull request body:

Hi all,

This pull request contains a backport of commit 775f48de from the openjdk/jdk repository.

The commit being backported was authored by Jasmine Karthikeyan on 9 Jan 2026 and was reviewed by Christian Hagedorn, Tobias Hartmann and Emanuel Peter.

Thanks!

If you need to update the source branch of the pull then run the following commands in a local clone of your personal fork of openjdk/jdk:

$ git fetch https://github.com/openjdk-bots/jdk.git backport-TobiHartmann-775f48de-jdk26:backport-TobiHartmann-775f48de-jdk26
$ git checkout backport-TobiHartmann-775f48de-jdk26
# make changes
$ git add paths/to/changed/files
$ git commit --message 'Describe additional changes made'
$ git push https://github.com/openjdk-bots/jdk.git backport-TobiHartmann-775f48de-jdk26

Fix truncation assert for constraint casts

d5c4dda

openjdk bot added hotspot-compiler hotspot-compiler-dev@openjdk.org rfr Pull request is ready for review labels Aug 18, 2025

eme64 reviewed Aug 20, 2025

View reviewed changes

Update comment for constraint casts

d6c81a9

eme64 approved these changes Aug 25, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Aug 25, 2025

chhagedorn reviewed Sep 16, 2025

View reviewed changes

eme64 mentioned this pull request Oct 15, 2025

8369881: C2: Unexpected node in SuperWord truncation: ReverseBytesS, ReverseBytesUS #27819

Closed

3 tasks

bridgekeeper bot closed this Nov 17, 2025

openjdk bot reopened this Nov 25, 2025

jaskarth added 2 commits December 3, 2025 23:00

Merge branch 'master' into jdk-8365570

0804af6

Remove CompLevel.C2 from test

f433930

openjdk bot removed the ready Pull request is ready to be integrated label Dec 5, 2025

jaskarth added 2 commits January 6, 2026 18:35

Merge branch 'master' into jdk-8365570

906af67

Update copyright year

ebe5a1d

Use Xcomp test run instead of Warmup(0)

50bc132

chhagedorn approved these changes Jan 7, 2026

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 7, 2026

TobiHartmann approved these changes Jan 7, 2026

View reviewed changes

eme64 approved these changes Jan 7, 2026

View reviewed changes

Revert "Use Xcomp test run instead of Warmup(0)"

0b445a5

This reverts commit 50bc132.

openjdk bot removed the ready Pull request is ready to be integrated label Jan 8, 2026

chhagedorn approved these changes Jan 8, 2026

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Jan 8, 2026

TobiHartmann approved these changes Jan 8, 2026

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Jan 9, 2026

openjdk bot closed this Jan 9, 2026

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 9, 2026

Conversation

jaskarth commented Aug 18, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Aug 18, 2025

Uh oh!

openjdk bot commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mlbridge bot commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eme64 commented Aug 22, 2025

Uh oh!

eme64 left a comment

Choose a reason for hiding this comment

Uh oh!

jaskarth commented Aug 25, 2025

Uh oh!

chhagedorn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bridgekeeper bot commented Oct 20, 2025

Uh oh!

bridgekeeper bot commented Nov 17, 2025

Uh oh!

TobiHartmann commented Nov 25, 2025

Uh oh!

jaskarth commented Nov 25, 2025

Uh oh!

jaskarth commented Nov 25, 2025

Uh oh!

openjdk bot commented Nov 25, 2025

Uh oh!

TobiHartmann commented Nov 28, 2025

Uh oh!

bridgekeeper bot commented Jan 4, 2026

Uh oh!

jaskarth commented Jan 6, 2026

Uh oh!

jaskarth commented Aug 18, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Aug 18, 2025 •

edited

Loading

openjdk bot commented Aug 18, 2025 •

edited

Loading

mlbridge bot commented Aug 18, 2025 •

edited

Loading