Mirror JPH per-arch VECTOR alignment so 32-bit ARM builds#24
Merged
Conversation
JPH defines `JPH_VECTOR_ALIGNMENT = 8` on 32-bit ARM (per `JoltPhysics/Jolt/Core/Core.h`: "32-bit ARM does not support aligning on the stack on 16 byte boundaries"), but the JoltC C-side typedefs hardcode `alignas(16)` for `JPC_Vec3` / `Vec4` / `Quat` / `Mat44` (and `alignas(32)` for `JPC_DVec3` / `DMat44`). The mismatch propagates: every settings struct that contains a vector field — `JPC_ShapeCastSettings`, `JPC_CollideShapeSettings`, `JPC_BodyManager_DrawSettings`, `JPC_ContactPoints`, `JPC_ContactManifold` — fails the `LAYOUT_COMPATIBLE` static_assert in `JoltCImpl/JoltC.cpp` with `align of JPC_<X> did not match align of JPH::<X> (16 == 8)`. Fix: introduce `JPC_VECTOR_ALIGNMENT` / `JPC_DVECTOR_ALIGNMENT` macros at the top of `JoltC/Functions.h` mirroring JPH's per-architecture branches (x86 / x86_64 / aarch64 / WASM / E2K get 16/32; 32-bit ARM gets 8/8; RISC-V splits on `__riscv_xlen`; PowerPC + LoongArch get 16/8). Replace the six load-bearing `alignas` literals on the vector / matrix typedefs with the macros; the value matches the original on every 64-bit target, so this is a no-op except on the 32-bit ARM path that previously failed the build. Verified locally: - x86_64-pc-windows-msvc host build: passes (no behaviour change) - aarch64-linux-android cross-compile via cargo-ndk r26d: passes - armv7-linux-androideabi cross-compile via cargo-ndk r26d: passes (previously failed at LAYOUT_COMPATIBLE static_assert)
Solidor777
added a commit
to Solidor777/Titan
that referenced
this pull request
May 8, 2026
Opened SecondHalfGames/JoltC#24 carrying the JPC_VECTOR_ALIGNMENT macros against upstream main (cherry-picked off the in-fork commit; TITAN PATCH marker stripped so upstream gets a clean diff). VENDORING.md + TODO.md gain the PR URL. When upstream merges, the in-fork patch becomes redundant — sync from upstream, bump the submodule, drop the "Local patches" entry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Merged
4 tasks
Contributor
Author
|
Verification breadcrumb: this fix is downstream-validated in CI on the Titan engine repo — Companion infrastructure PR (independent — ships the cargo-ndk integration on |
LPGhatguy
approved these changes
May 11, 2026
Solidor777
added a commit
to Solidor777/Titan
that referenced
this pull request
May 17, 2026
Opened SecondHalfGames/JoltC#24 carrying the JPC_VECTOR_ALIGNMENT macros against upstream main (cherry-picked off the in-fork commit; TITAN PATCH marker stripped so upstream gets a clean diff). VENDORING.md + TODO.md gain the PR URL. When upstream merges, the in-fork patch becomes redundant — sync from upstream, bump the submodule, drop the "Local patches" entry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Solidor777
added a commit
to Solidor777/Titan
that referenced
this pull request
Jun 4, 2026
Opened SecondHalfGames/JoltC#24 carrying the JPC_VECTOR_ALIGNMENT macros against upstream main (cherry-picked off the in-fork commit; TITAN PATCH marker stripped so upstream gets a clean diff). VENDORING.md + TODO.md gain the PR URL. When upstream merges, the in-fork patch becomes redundant — sync from upstream, bump the submodule, drop the "Local patches" entry. Co-Authored-By: Claude Opus 4.7 <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
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.
Problem
JoltC's
LAYOUT_COMPATIBLEstatic_asserts inJoltCImpl/JoltC.cppfail on 32-bit ARM targets (armv7 Android, armv7 Linux):…and the same for
JPC_Vec4,JPC_DVec3,JPC_Quat,JPC_Mat44,JPC_DMat44,JPC_RVec3, plus every higher-level struct that contains a vector field (JPC_ShapeCastSettings,JPC_CollideShapeSettings,JPC_BodyManager_DrawSettings,JPC_ContactPoints,JPC_ContactManifold).Root cause
JoltPhysics/Jolt/Core/Core.h:180defines:JoltC's C-side typedefs in
JoltC/Functions.hhardcodealignas(16)onJPC_Vec3/Vec4/Quat/Mat44andalignas(32)onJPC_DVec3/JPC_DMat44. On 32-bit ARM the C-side over-constrains relative to JPH; the static_assert fires.Fix
Introduce
JPC_VECTOR_ALIGNMENT/JPC_DVECTOR_ALIGNMENTmacros at the top ofJoltC/Functions.hmirroring the same per-arch logic JPH uses (x86 / x86_64 / aarch64 / WASM / E2K → 16/32; 32-bit ARM → 8/8; RISC-V splits on__riscv_xlen; PowerPC + LoongArch → 16/8). Replace the six load-bearingalignas(...)literals on the vector / matrix typedefs with the macros.The macro values match the original on every 64-bit target, so this is a no-op except on the 32-bit ARM path that previously failed the build.
Verification
cargo ndkr26d: passes.cargo ndkr26d: passes (previously failed at LAYOUT_COMPATIBLE).