Skip to content

V8 build error with 22.7.0 #54576

Description

@bnoordhuis

Like #53633 which was for gcc 12 and fixed in commit f4a7ac5 but with clang 15.0.7 on x86_64 linux I get the exact same build error:

../deps/v8/src/base/small-vector.h:25:3: error: static assertion failed due to requirement '::v8::base::is_trivially_copyable<std::pair<const v8::internal::com
piler::turboshaft::PhiOp *, const v8::internal::compiler::turboshaft::OpIndex>>::value': T should be trivially copyable                                        
  ASSERT_TRIVIALLY_COPYABLE(T);                                                                                                                                
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                                                 
../deps/v8/src/base/macros.h:211:3: note: expanded from macro 'ASSERT_TRIVIALLY_COPYABLE'                                                                      
  static_assert(::v8::base::is_trivially_copyable<T>::value, \                                                                                                 
  ^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                    
../deps/v8/src/compiler/turboshaft/loop-unrolling-reducer.h:431:65: note: in instantiation of template class 'v8::base::SmallVector<std::pair<const v8::interna
l::compiler::turboshaft::PhiOp *, const v8::internal::compiler::turboshaft::OpIndex>, 16>' requested here                                                      
  base::SmallVector<std::pair<const PhiOp*, const OpIndex>, 16> phis;

Maybe just remove that ASSERT_TRIVIALLY_COPYABLE? Upstream already tests for correctness and to us it's just a recurring source of build breakage.

Activity

  1. added
    confirmed-bugIssues and PRs for confirmed bugs.
    buildIssues and PRs related to Node.js builds or CI infrastructure.
    v8 engineIssues and PRs related to the V8 dependency.
    on Aug 26, 2024
  2. joyeecheung commented on Aug 27, 2024

    @joyeecheung
    Member

    Another option would be to pile the affected clang versions onto the ifdef mixture. According to the minimal repro this seems specific to clang 15 (doesn't reproduce on neither clang 14.0.0 nor 16.0.0)

  3. joyeecheung commented on Aug 27, 2024

    @joyeecheung
    Member

    Actually I remember we are using clang 15 for macOS in the canary CI? @targos

  4. targos commented on Aug 27, 2024

    @targos
    Member

    There's nothing special about the canary CI. It's using the same machines and config as main

  5. targos commented on Aug 27, 2024

    @targos
    Member

    According to https://en.wikipedia.org/wiki/Xcode#Xcode_11.0_-_14.x_(since_SwiftUI_framework)_2, clang 15 wasn't included for a long time in Xcode (it's the LLVM column):

    CleanShot 2024-08-27 at 16 22 45

  6. bnoordhuis commented on Sep 19, 2024

    @bnoordhuis
    MemberAuthor

    I've seen this bug with both clang 14 and 15. What do our buildbots use? 16?

  7. bnoordhuis commented on Sep 19, 2024

    @bnoordhuis
    MemberAuthor

    Forgot to mention, I have a patch ready for upstreaming but I'd like to narrow down the range of broken clangs.

  8. targos commented on Sep 19, 2024

    @targos
    Member

    In Jenkins, the buildbots use Clang 12
    In GitHub actions, it seems to be Apple Clang 15 (LLVM 16).

    (on macOS)

  9. targos commented on Sep 19, 2024

    @targos
    Member

    on Linux, I think we only use Clang in GitHub actions, and it's on version 18.

  10. richardlau commented on Sep 20, 2024

    @richardlau
    Member

    Just hit this with FreeBSD 13.3 and clang 17.0.6.

    FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)
    Target: x86_64-unknown-freebsd13.3
    Thread model: posix
    InstalledDir: /usr/bin
    
  11. bnoordhuis commented on Sep 20, 2024

    @bnoordhuis
    MemberAuthor
  12. richardlau commented on Oct 1, 2024

    @richardlau
    Member

    https://chromium-review.googlesource.com/c/v8/v8/+/5872655 - restricted to clang <= 17.

    FYI I tried this out on FreeBSD 13 (clang 17.0.6) but that hasn't fixed the build.

    (CI with richardlau@953b8e3): https://ci.nodejs.org/job/richardlau-node-test-commit-freebsd/11/nodes=freebsd13-x64/consoleFull

  13. deleted a comment from on Mar 10, 2025
  14. renchap commented on Apr 22, 2025

    @renchap

    This is still happening with Node v22.14.0 and FreeBSD 14.2 and clang 18.1.5

  15. bnoordhuis commented on Apr 22, 2025

    @bnoordhuis
    MemberAuthor

    Looks like I forgot to merge the upstream patch. It took a couple of days to get reviewed and I get way too much email so I probably missed the notification.

    I'm not that invested myself anymore but @renchap you're welcome to adopt and resubmit it, no attribution required.

  16. jonhermansen commented on Nov 4, 2025

    @jonhermansen

    @bnoordhuis Is it alright if I re-submit the patch?

    Seeing the same problem on FreeBSD 15.0-BETA4 with clang 19

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.confirmed-bugIssues and PRs for confirmed bugs.v8 engineIssues and PRs related to the V8 dependency.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions