Originally spotted when the CI started failing in my #1047 request, but when running the hxcpp tests with haxe 4.3.1 on MSVC for HXCPP_M64 with the debug flag set and the msvc toolchain modified to enable C++17 <flag value="/std:c++17"/>, the testObject, testFunc, testCustomObject, and testBytes zombie tests start to fail. The last three of these seem to be a knock on from the first failing test.
testObject is failing with the zombie from the GC being null. Stepping through things with visual studio, when FindZombies is called during collection the object marked as do not kill is never moved into the zombie list as it's mark byte has been set.
Assuming that this is due to some new aggressive optimisation MSVC can now do I started to modify the code a bit, seeing that clearStack has a nothing argument which, as the name suggests, does nothing I added a few more assuming that it exists to avoid compiler optimisations. Adding four more nothing arguments to that clearStack function then gets all four of those tests to start passing again! It is odd that this only happens with the debug flag, I'd have though thses sort of optimisations would be reserved for release modes.
I'm planning on not requiring C++17 for #1047, but its something to be aware of atleast...
Originally spotted when the CI started failing in my #1047 request, but when running the hxcpp tests with haxe 4.3.1 on MSVC for HXCPP_M64 with the debug flag set and the msvc toolchain modified to enable C++17
<flag value="/std:c++17"/>, thetestObject,testFunc,testCustomObject, andtestByteszombie tests start to fail. The last three of these seem to be a knock on from the first failing test.testObjectis failing with the zombie from the GC being null. Stepping through things with visual studio, whenFindZombiesis called during collection the object marked as do not kill is never moved into the zombie list as it's mark byte has been set. Assuming that this is due to some new aggressive optimisation MSVC can now do I started to modify the code a bit, seeing thatclearStackhas anothingargument which, as the name suggests, does nothing I added a few more assuming that it exists to avoid compiler optimisations. Adding four more nothing arguments to thatclearStackfunction then gets all four of those tests to start passing again! It is odd that this only happens with the debug flag, I'd have though thses sort of optimisations would be reserved for release modes.I'm planning on not requiring C++17 for #1047, but its something to be aware of atleast...