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>
alexdummer
pushed a commit
to MAteRialMOdelingToolbox/Marmot
that referenced
this pull request
Aug 17, 2026
* fix: use a shift instead of non-constexpr std::pow for nNodesLinear
std::pow is not constexpr in the C++ standard. libstdc++ provides a
non-standard constexpr overload, so this compiles on the Linux/GCC CI, but
libc++ (macOS/clang, incl. arm64) rejects it:
error: constexpr variable 'nNodesLinear' must be initialized by a
constant expression
2^nDim is exactly a shift for the dimensions in use, so use 1 << nDim.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test: fix two latent bugs in the test suite exposed on arm64 macOS
Both tests pass on the Ubuntu CI (GCC/libstdc++) but are defective; one of
them fails outright with clang/libc++ on Apple Silicon. The library code is
correct in both cases — only the tests are at fault.
1. TestMarmotVoigt — the four dJ2/dJ3 stress/strain derivative checks compare
an analytic derivative against a forward-difference approximation, but omit
the tolerance argument to checkIfEqual(), so they inherit the default
tol = 1e-15. A first-order forward difference with a 1e-8 step cannot meet
that; the checks only pass where the two happen to round identically.
On arm64/clang they do not:
Hint: a = 17.6068 != b = 17.6068 ( tol = 1e-15 )
Exception: void test_dJ2_dStress() failed
Reproduced 5/5 runs. The sibling finite-difference checks in the same file
already pass 1e-8 explicitly; this makes these four consistent with them.
2. TestMarmotFiniteStrainPlasticity — the reference tensor DexMapexpect is a
Fastor::Tensor<double,3,3,3,3>, which is not zero-initialized, and the test
assigns only the non-zero components. The remaining 80 entries are read
uninitialized, which is undefined behaviour.
This one currently passes, because a fresh stack happens to be zeroed. It
is luck, not correctness: dirtying the stack before the tensor is
constructed leaves all 80 unset entries holding garbage (values up to
1e29). Added an explicit .zeros() so the reference is well-defined.
Verified on macOS 15 / Apple M4, clang 20 (conda-forge
arm64-apple-darwin20.0.0-clang++), -std=c++20 -stdlib=libc++, Release:
before 45/46 ctests pass, after 46/46.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix: give MarmotMaterialGeneralGradientEnhancedHypoElastic a virtual destructor
The class is abstract and instances are owned and destroyed through
base-class pointers — GeneralGradientEnhancedDisplacementFiniteElement holds
one per quadrature point as
std::unique_ptr< MarmotMaterialGeneralGradientEnhancedHypoElastic< N > > material;
Destroying a derived object through a base pointer whose destructor is not
virtual is undefined behaviour ([expr.delete]/3). GCC/libstdc++ happens to
call the wrong destructor silently, which is why the Ubuntu CI never noticed;
clang diagnoses it and, because the UB is provable, emits a trap instead of a
call, so the process dies at the point of destruction.
Reproduced on macOS 15 / Apple M4, clang 20, -std=c++20 -stdlib=libc++, in
five lines against an otherwise unmodified tree:
double props[] = {20000., 0.2, 1.0, 0.1, 1.0, 1.0};
auto* m = MarmotLibrary::MarmotMaterialGeneralGradientEnhancedHypoElasticFactory<1>
::createMaterial("AT2PHASEFIELD", props, 6, 1);
delete m;
warning: delete called on 'MarmotMaterialGeneralGradientEnhancedHypoElastic<1>'
that is abstract but has non-virtual destructor
[-Wdelete-abstract-non-virtual-dtor]
$ ./repro
material ptr = 0x121804320
[SIGTRAP, exit 133]
With this change the warning disappears and the same program exits 0. Note
that the existing TestAT2PhaseField ctest does not catch this — it passes
either way, because it never destroys a material through the base pointer.
Three sibling classes are abstract with a non-virtual destructor for the same
reason and are latent rather than currently broken, since nothing in-tree
deletes them through a base pointer yet: MarmotMaterialFiniteStrainAD,
MarmotMaterialHypoElasticAD, and MarmotMaterialPointSolver{FiniteStrain,
HypoElastic}. Happy to fix those in this PR too if preferred.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* ci: add a macOS/arm64 build
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>
* ci: make build_ubuntu fail on errors instead of reporting green
Same hardening as the new macOS job, applied to the existing Linux one. No
functional change while everything passes — this only affects what happens
when something breaks.
Two ways the job could report success without having built anything:
* Specifying `shell:` replaces GitHub's default `bash -e {0}`, so `bash -l {0}`
silently drops errexit. Only the last command of a `run:` block then decides
the step result, and the three dependency steps end in `cd ../..`, which
always succeeds. A failed clone, cmake or `make install` was therefore
reported as a passing step, and only surfaced later as a confusing
"include directory not found" from Marmot's own configure — or not at all.
* `ctest` exits 0 when no tests exist, so a build that produced no test
binaries still passed.
This was not hypothetical: the macOS job hit exactly this and reported success
having compiled nothing. On Linux the steps all currently succeed, so the
problem is latent rather than active, but the failure mode is the same.
Uses `bash -leo pipefail {0}` and `ctest --no-tests=error`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
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.