Fix freestanding no malloc guards - #4
Merged
patkenneally merged 2 commits intoAug 25, 2026
Merged
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.
Make EIGEN_NO_MALLOC mean something in release builds
Two independent fixes to freestanding Eigen, found while investigating four
-Wreturn-typewarnings in ariscv32-elf-g++ -Os -DNDEBUGbuild.EIGEN_NO_MALLOCallocation entry points instead of assertingMemory.hguarded six allocators with bodies that contained onlyeigen_assert(false && "heap allocation is forbidden"). UnderNDEBUG,eigen_plain_assertexpands to nothing (Macros.h:1004-1017), so those became empty functions returningvoid*- undefined behaviour if ever called.This is
NDEBUG-specific rather than target-specific: it reproduces on a host withg++-13 -DEIGEN_FREESTANDING=1 -DNDEBUGand disappears without-DNDEBUG.The six (
handmade_aligned_malloc/free/realloc,conditional_aligned_malloc/free/realloc<false>) are now deleted declarations underEIGEN_NO_MALLOC. No body means no warning and no fall-through, and any real use becomes a compile error naming the caller.Safe to delete: in freestanding
EIGEN_DEFAULT_ALIGN_BYTES == 0, soaligned_malloctakes the plain-mallocbranch and never reacheshandmade_aligned_*. Runningnmon compiled products confirms none of these symbols are referenced.allocaas a macro so Eigen detects itFreestanding/portable_stdlib.hdeclaredallocaas anextern "C"function, but Eigen selects its stack-allocation path with#if ... || (defined alloca)(
Memory.h:613) — a macro test, which a declaration never satisfies.Consequence:
EIGEN_ALLOCAstayed undefined on the freestanding target, soei_declare_aligned_stack_constructed_variablefell to the#elsebranch atMemory.h:794, which callsaligned_mallocunconditionally, at any size, with noEIGEN_STACK_ALLOCATION_LIMITcheck. Hosted builds haveallocaand keep small temporaries on the stack, which is why this never showed up there.Replaced with
#define alloca __builtin_alloca, which GCC emits inline on every target including RISC-V. VerifiedEIGEN_ALLOCAis now defined underriscv32-elf-g++ -ffreestanding.EIGEN_STACK_ALLOCATION_LIMITis deliberately left at its default: it is overloaded between that ternary and a static assert capping fixed-size stack objects (DenseStorage.h:33), so tuning it for one breaks the other.Scope
Both changes are inside
#ifdef EIGEN_NO_MALLOC/ the freestanding branch. The#elsepaths keep the original definitions, so hosted and normal Eigen builds are untouched.Testing
-fsyntax-onlyon<Eigen/Dense>clean in three configurations: RV32 freestanding-Os -DNDEBUG, RV32 freestanding-Og, and hosted-O2plain Eigen.