Fix riscv generic target detection#87
Open
carlosqwqqwq wants to merge 1 commit into
Open
Conversation
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.
Why
BitMagic already has a portable non-SIMD baseline, but two parts of the project still inherit host-specific x86 assumptions during simulated or cross-target
riscv64builds:src/bmdef.hderivesBM_x86andBM_UNALIGNED_ACCESS_OKdirectly from host compiler macros, which can leak x86 inline-assembly and memory-access assumptions intoriscv64target validation.CMakeLists.txtinjects-march=nativeby default for GNU/Clang builds, which is appropriate for native x86 builds but not for cross-target or simulatedriscv64configurations.What changed
src/bmdef.hto recognize__riscvfirst and defineBM_RISCV.BM_x86andBM_UNALIGNED_ACCESS_OKfrom being inferred when the selected target is RISC-V.CMakeLists.txtso the default GNU/Clang path only applies-march=nativefor non-cross x86 targets, while non-x86 or cross-target builds fall back to generic-O2flags unless an explicit SIMD profile is requested.README.mdto document thatriscv64should use the default portable build unless a dedicated RISC-V SIMD backend is added.Verification
src/bmdef.hwith forced__riscv=1and__riscv_xlen=64and confirmedBM_RISCVis defined whileBM_x86andBM_UNALIGNED_ACCESS_OKare no longer defined.riscv64smoke translation unit includingbm.hand confirmed the generic path builds successfully without leaking x86-only assumptions.cmake -S . -B build-native-min -G Ninja -DCMAKE_BUILD_TYPE=Releasebmsvutiltarget successfully:cmake --build build-native-min --target bmsvutil --parallel 4build\bin\bmsvutil.exeriscv64CMake configuration:cmake -S . -B build-riscv-config -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=riscv64 -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARYbuild-riscv-config/build.ninjaand confirmed the generated compile flags no longer contain-march=native,-msse4.2,-mavx2,BMSSE42OPT, orBMAVX2OPT.samples/svsample10/svsample10.cppexample to a staticriscv64executable with-std=c++17.filereadelf -hqemu-riscv64and confirmed the expected scanner output is produced end-to-end.Notes
This is a conservative portability patch. It does not add RVV or any other RISC-V SIMD backend. The goal is to keep
riscv64on BitMagic's existing generic implementation path and to stop host x86 configuration details from leaking into target selection and validation.As of the 2026-06-19 fresh upstream sync audit, this branch is currently
1 ahead / 1 behindupstream/master. The missing upstream commit isa885ae4e(added is_all to when to test svf), which only touchestests/stress/t.cppand does not overlap this patch's migration files (CMakeLists.txt,src/bmdef.h,README.md). A manual upstream PR should still be created from a rebased or otherwise synchronized branch, but the current drift is a branch-maintenance issue rather than evidence that the RISC-V patch itself has already gone stale.