fix: load ARM64 NEON constant via vld1q_u16 instead of guessing MSVC's struct layout - #640
Merged
Merged
Conversation
…llow-up to #637) The nested-braces fix (#639) wasn't enough - MSVC's ARM64 uint16x8_t still rejected the aggregate init with the same error C2078, just pointing at slightly different columns. Rather than keep guessing at MSVC's exact internal struct layout, sidestep it entirely: keep the constant data as a plain uint16_t[8] array (always valid as a static initializer, no vector-type ambiguity) and load it into the vector register with the portable vld1q_u16 intrinsic, already used throughout this file (e.g. vld1_u8 at line 3416+). Closes #636
github-actions
Bot
added
area: ci
This was referenced Jul 28, 2026
BenJule
added a commit
that referenced
this pull request
Jul 28, 2026
…#642) After #640 fixed the NEON/SIMD compile errors, the ARM64 nightly build got all the way through compilation and failed at link time instead: ``` libslic3r_gui.lib(wxMediaCtrl3.obj) : error LNK2001: unresolved external symbol "AVVideoDecoder::AVVideoDecoder(void)" ... 6 unresolved externals total BambuStudio.dll : fatal error LNK1120: 6 unresolved externals ``` CMakeLists.txt excludes `AVVideoDecoder.cpp`/`.hpp` from the ARM64 source list entirely (no prebuilt libav there), but `wxMediaCtrl3.cpp` unconditionally includes the header and declares an `AVVideoDecoder` instance. The header itself compiles fine (it's just a class declaration), but there's no `.cpp` providing the implementation, hence the link failure. Rather than touching the ~130-line streaming thread in `wxMediaCtrl3.cpp` with a spread of `#ifdef`s, this moves the exclusion inside `AVVideoDecoder.cpp`/`.hpp`: the real libav-based implementation is guarded by the already-existing `BAMBUSTUDIO_NO_AVVIDEODECODER` define (already set for MSVC ARM64 at CMakeLists.txt:760), with a stub implementation for when it's defined that always reports failure. The file is now always part of `SLIC3R_GUI_SOURCES` instead of being conditionally excluded. `wxMediaCtrl3.cpp` needs zero changes - camera/live-view will just report "no frame" on ARM64 instead of the whole binary failing to link. Closes #641
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#639's nested-braces fix wasn't enough - the nightly rebuild still failed with the exact same error C2078 on the same line, just different columns. Rather than keep guessing at how MSVC's arm64_neon.h actually lays out uint16x8_t internally, this sidesteps the whole aggregate-init question:
A plain
uint16_t[8]array is always a valid static initializer on every compiler - no vector-type ambiguity possible.vld1q_u16is the same portable ACLE load intrinsic family already used throughout this file (vld1_u8etc.), so it's guaranteed to work wherever NEON already builds. Only downside: loses thestaticon the vector itself, so it's now loaded fresh per call instead of computed once - negligible cost for a single 128-bit load.Closes #636