← All tasks
cppjrouwe/JoltPhysics #922Not a task: already works

Compiling with double-precision for macOS <10.14 fails

envgap__jrouwe__JoltPhysics-922

01 / FAILURE SIGNATURE

As reported upstream

Jolt/Physics/Character/Character.cpp:135:8: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer
Not a benchmark task.
  • The project already builds and runs before the fix, so there is nothing to repair.

02 / ENVIRONMENT RECIPE

Base commit
958b6558c873a1ce2631fc4ac05ecbe9df1d4a32
Manifest
Build/CMakeLists.txt
Reproduce
Awaiting issue-specific recipe
Run under trace
Awaiting a meaningful runtime command

03 / ORIGINAL ISSUE TEXT

jrouwe/JoltPhysics #922 · read the original issue
This one has me scratching my head a bit, but it seems like there's something going on with the collector classes in `Character` and `CharacterVirtual` when compiling double-precision builds for macOS >=10.12 (Sierra), where I get the following errors:



```

Jolt/Physics/Character/Character.cpp:135:8: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

        class MyCollector : public CollideShapeCollector

              ^

Jolt/Physics/Character/Character.cpp:139:14: note: in implicit destructor for 'MyCollector' first required here

                explicit                        MyCollector(Vec3Arg inUp, RVec3 inBaseOffset) : mBaseOffset(inBaseOffset), mUp(inUp) { }

                                                ^

Jolt/Physics/Character/Character.cpp:135:8: note: if you supply your own aligned allocation functions, use -faligned-allocation to silence this diagnostic

        class MyCollector : public CollideShapeCollector

              ^

```



```

Jolt/Physics/Character/CharacterVirtual.h:363:8: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

        class ContactCollector : public CollideShapeCollector

              ^

Jolt/Physics/Character/CharacterVirtual.cpp:235:19: note: in implicit destructor for 'JPH::CharacterVirtual::ContactCollector' first required here

        ContactCollector collector(mSystem, this, mMaxNumHits, mHitReductionCosMaxAngle, mUp, mPosition, outContacts);

                         ^

Jolt/Physics/Character/CharacterVirtual.h:363:8: note: if you supply your own aligned allocation functions, use -faligned-allocation to silence this diagnostic

        class ContactCollector : public CollideShapeCollector

              ^

Jolt/Physics/Character/CharacterVirtual.h:381:8: error: aligned deallocation function of type 'void (void *, std::align_val_t) noexcept' is only available on macOS 10.14 or newer

        class ContactCastCollector : public CastShapeCollector

              ^

Jolt/Physics/Character/CharacterVirtual.cpp:348:23: note: in implicit destructor for 'JPH::CharacterVirtual::ContactCastCollector' first required here

        ContactCastCollector collector(mSystem, this, inDisplacement, mUp, inIgnoredContacts, start.GetTranslation(), contact);

                             ^

Jolt/Physics/Character/CharacterVirtual.h:381:8: note: if you supply your own aligned allocation functions, use -faligned-allocation to silence this diagnostic

        class ContactCastCollector : public CastShapeCollector

              ^

```



The repro should hopefully be as simple as compiling on macOS with the following additional CMake defines:



```

-DDOUBLE_PRECISION=YES

-D"CMAKE_OSX_DEPLOYMENT_TARGET=10.12"

-D"CMAKE_OSX_ARCHITECTURES=x86_64;arm64"

```



(I don't have access to a macOS machine at the moment, so this is purely from messing around with Godot Jolt through GitHub Actions.)



From what I understand these errors have to do with the alignment of these classes being greater than `sizeof(max_align_t)`, which supposedly causes the compiler to rely on the global aligned new/delete operators in some generated code, which isn't available prior to macOS 10.14. What's weird about this is that I believe `sizeof(max_align_t)` is 8 bytes on Apple Silicon, so I feel like I should be seeing these errors even without `DOUBLE_PRECISION=YES`, but I don't.



Seeing as how these classes are only ever stack-allocated, and any heap-allocated type uses the class operators through `JPH_OVERRIDE_NEW_DELETE` anyway, I assume it would be relatively safe to use the `-faligned-allocation` flag as suggested in the error messages, but I figured I'd check to see if you had any other ideas/theories.



EDIT: I also tried adding `JPH_OVERRIDE_NEW_DELETE` to these collector classes, but it made no difference.

EDIT 2: Thinking about it some more, I guess the reason this doesn't show up without `DOUBLE_PRECISION=YES` is because Apple Silicon probably implies a minimum macOS version of 11 (Big Sur) and x64 has a `sizeof(max_align_t)` of 16, which would line up with `JPH_VECTOR_ALIGNMENT` and thus the collectors wouldn't be over-aligned, maybe?
Continue on GitHub ↗

04 / LABELS

Labels from the report text only; not yet run

No supported category has been assigned.

Label rules and the text that matched
[]