Skip to content

build: riscv64 Clang 19 build fails in V8 MutablePage cache-line assertion #67428

Open

Description

@yuzibo

Version

Node.js master branch (upstream origin/master, tested on November 6, 2026; exact commit not record).

Platform

Linux v100-001 7.0.0-42-generic #42.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 16 15:53:30 UTC 2026 riscv64 GNU/Linux

Subsystem

v8

What steps will reproduce the bug?

    ./configure --error-on-warn --v8-enable-temporal-support 
    make -j"$(getconf _NPROCESSORS_ONLN)" 
    make test-ci -j1 V=1 TEST_CI_ARGS="-p actions --measure-flakiness 9

How often does it reproduce? Is there a required condition?

always

What is the expected behavior? Why is that the expected behavior?

Build and test will be passed.

What do you see instead?

But it fail to build on this riscv64 hardware

#8 1157.2   132 | # define _GLIBCXX20_DEPRECATED_SUGGEST(ALT) _GLIBCXX_DEPRECATED_SUGGEST(ALT)
#8 1157.2       |                                             ^
#8 1157.2 /usr/lib/gcc/riscv64-linux-gnu/14/../../../../include/riscv64-linux-gnu/c++/14/bits/c++config.h:100:19: note: expanded from macro '_GLIBCXX_DEPRECATED_SUGGEST'
#8 1157.2   100 |   __attribute__ ((__deprecated__ ("use '" ALT "' instead")))
#8 1157.2       |                   ^
#8 1157.3   CXX(target) /home/jenkins/node/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/ic/ic-stats.o
#8 1157.6 2 warnings generated.
#8 1157.8   CXX(target) /home/jenkins/node/out/Release/obj.target/v8_base_without_compiler/deps/v8/src/ic/ic.o
#8 1158.0 ../deps/v8/src/heap/mutable-page.cc:53:7: error: static assertion failed due to requirement 'kOffsetOfFirstFastField / std::hardware_destructive_interference_size == kOffsetOfLastFastField / std::hardware_destructive_interference_size'
#8 1158.0    53 |       kOffsetOfFirstFastField / std::hardware_destructive_interference_size ==
#8 1158.0       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#8 1158.0    54 |       kOffsetOfLastFastField / std::hardware_destructive_interference_size);
#8 1158.0       |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#8 1158.0 ../deps/v8/src/heap/mutable-page.cc:53:77: note: expression evaluates to '2 == 3'
#8 1158.0    53 |       kOffsetOfFirstFastField / std::hardware_destructive_interference_size ==
#8 1158.0       |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
#8 1158.0    54 |       kOffsetOfLastFastField / std::hardware_destructive_interference_size);
#8 1158.0       |       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#8 1158.2 In file included from ../deps/v8/src/heap/minor-mark-sweep.cc:5:

see the log.

Additional information

While bringing up a Nodejs CI job on native riscv64 hardware, we encountered a build failure in the bundled V8. With Clang 19 on Debian Trixie, the cache-line locality assertion in deps/v8/src/heap/mutable-page.cc fails, with the expression evaluating to 2 == 3. The build stops before tests can run.

Is this a known layout limitation for native riscv64 builds, or should the assertion/layout be adjusted for this configuration?

Activity

  1. added
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    riscv64Issues and PRs related to the 64-bit RISC-V architecture.
    on Nov 12, 2026
  2. inoway46 commented on Nov 12, 2026

    @inoway46
    Contributor

    This looks like the same failure I hit in cross-builds for #66803 and reported upstream as V8 issue 574828088.

    In that build, std::hardware_destructive_interference_size was 32 on RISC-V. heap_ sits at offset 64, and the end of slot_set_[OLD_TO_NEW] at offset 96. Dividing by 32 gives 2 == 3, the same result as in your log. The check used /64 before V8 commit 16d931df, which would give 1 == 1.

    Your report shows the failure is not specific to GCC 15: it also happens in a native build with Clang 19. As a local workaround, restoring /64 in deps/v8/src/heap/mutable-page.cc lets the file compile. My cross-build (with Temporal enabled) passed with that change, together with #66823 and the Highway fix from V8 CL 8604548. You may hit those other issues after this one.

    The proper fix needs to land in V8. I've proposed one in V8 CL 8605052, and noted this report on V8 issue 574828088.

  3. yuzibo commented on Nov 12, 2026

    @yuzibo
    Author

    yeah, I just noticed this from the comment also.

    Thanks for explanations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    buildIssues and PRs related to Node.js builds or CI infrastructure.riscv64Issues and PRs related to the 64-bit RISC-V architecture.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions