Repository navigation
Open
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.riscv64Issues and PRs related to the 64-bit RISC-V architecture.Issues and PRs related to the 64-bit RISC-V architecture.
Description
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?
Metadata
Metadata
Assignees
Labels
buildIssues and PRs related to Node.js builds or CI infrastructure.Issues and PRs related to Node.js builds or CI infrastructure.riscv64Issues and PRs related to the 64-bit RISC-V architecture.Issues and PRs related to the 64-bit RISC-V architecture.
Activity
inoway46 commentedon Nov 12, 2026
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_sizewas 32 on RISC-V.heap_sits at offset 64, and the end ofslot_set_[OLD_TO_NEW]at offset 96. Dividing by 32 gives2 == 3, the same result as in your log. The check used/64before V8 commit 16d931df, which would give1 == 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
/64indeps/v8/src/heap/mutable-page.cclets 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.
yuzibo commentedon Nov 12, 2026
yeah, I just noticed this from the comment also.
Thanks for explanations.