Guard CPUID/rdtsc for non-x86 and add stubs - #182
Open
chemiskyy wants to merge 1 commit into
Open
Conversation
Add explicit x86/x86_64 guards and non-x86 fallbacks for CPUID and rdtsc. In Fastor/config/cpuid.h, avoid using inline asm on non-x86 targets by checking for __x86_64__/__i386__ and provide a safe zeroed fallback for regs otherwise. In Fastor/util/timeit.h, restrict the GCC inline-asm rdtsc implementation to x86 and add ARM/non-x86 stub implementations that return 0. These changes prevent build failures on non-x86 platforms and make the codebase more portable.
mitrlk
added a commit
to mitrlk/mitrlk-Marmot
that referenced
this pull request
Aug 10, 2026
Mirrors build_ubuntu, but on GitHub's Apple Silicon runner (macos-latest is arm64 since macos-14). This exercises clang/libc++ rather than GCC/libstdc++, which is what makes the three fixes in this PR necessary — all of them are accepted silently by libstdc++ and rejected or trapped by libc++. Without this job the same problems can reappear unnoticed, since nothing else in CI compiles Marmot with libc++. CC/CXX are pinned to clang/clang++ rather than left to CMake's default: the macOS runners also ship Homebrew GCC, and silently picking that up would build against libstdc++ and defeat the purpose of the job while still reporting green. No compiler version is pinned, so the job tracks whatever Apple clang the runner provides. A first step prints the toolchain so the log records which compiler actually ran. One deviation from build_ubuntu: Fastor is cloned from an arm64-compatible fork rather than upstream V0.6.4. Upstream Fastor does not compile on arm64 — it reaches x86 `cpuid` and `rdtsc` inline assembly on every non-Windows platform, and its scalar fallback backend has further defects that only surface off x86. The fork is upstream `master` plus the minimal patch fixing exactly that, and nothing else. Those fixes are offered upstream in romeric/Fastor#182 and #183; the step carries a comment to switch back once either is merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mitrlk
added a commit
to mitrlk/mitrlk-Marmot
that referenced
this pull request
Aug 10, 2026
Mirrors build_ubuntu, but on GitHub's Apple Silicon runner (macos-latest is
arm64 since macos-14). This exercises clang/libc++ rather than GCC/libstdc++,
which is what makes the three fixes in this PR necessary — all of them are
accepted silently by libstdc++ and rejected or trapped by libc++.
Without this job the same problems can reappear unnoticed, since nothing else
in CI compiles Marmot with libc++.
Deviations from build_ubuntu, each deliberate:
* The autodiff build directory is called `build-cmake`, not `build`. autodiff
ships a Bazel `BUILD` file in its repository root, and the macOS filesystem
is case-insensitive, so `mkdir build` fails with "File exists" and `cd build`
with "Not a directory". On Linux the two names are distinct, which is why
build_ubuntu is unaffected.
* `shell: bash -leo pipefail {0}` rather than `bash -l {0}`. Specifying a
shell replaces GitHub's default `bash -e {0}`, so `-l` alone silently drops
errexit and only the last command of a `run:` block decides the step result.
Since the dependency steps end in `cd ../..`, the autodiff failure above was
reported as success and only surfaced later as a confusing "autodiff include
directory not found". The same pattern is present in build_ubuntu, where it
is currently latent because those steps all succeed.
* `ctest --no-tests=error`. ctest exits 0 when no tests exist, so a build that
produced no test binaries at all still reported success.
* CC/CXX pinned to clang/clang++ rather than left to CMake's default: the
macOS runners also ship Homebrew GCC, and silently picking that up would
build against libstdc++ and defeat the purpose of the job while still
reporting green. No compiler version is pinned, so the job tracks whatever
Apple clang the runner provides. A first step prints the toolchain so the
log records which compiler actually ran.
* Fastor is cloned from an arm64-compatible fork rather than upstream V0.6.4.
Upstream Fastor does not compile on arm64 — it reaches x86 `cpuid` and
`rdtsc` inline assembly on every non-Windows platform, and its scalar
fallback backend has further defects that only surface off x86. The fork is
upstream `master` plus the minimal patch fixing exactly that, and nothing
else. Those fixes are offered upstream in romeric/Fastor#182 and #183; the
step carries a comment to switch back once either is merged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
Proposed fix for ARM:
Fastor/config/cpuid.h — The CPUID class constructor uses x86 cpuid asm in an unguarded #else. Fix: gate it with #elif defined(x86_64) || defined(i386)
and add an #else that zeros the registers on ARM.
Fastor/util/timeit.h — The rdtsc() / rdtsc_begin() / rdtsc_end() functions use x86 rdtsc/rdtscp asm in an unguarded #else. Fix: same #elif x86 gate, plus ARM
stubs that return 0.