With this instruction set the MSVC emits unconditional usage of the instructions vpxor and vmovdqu when constructing a std::shared_ptr. On older CPU models that don't support the AVX instruction set this will result in a crash. It was quite frustrating to figure this out given that less than 1% of my users appear to be affected.
Maybe this instruction set could not be unconditionally applied to libnyquist when built from CMake? Or maybe the usage of std::shared_ptr can be reduced. Given that all decoders are stateless and 1-byte large there's next to not good reason to use std::shared_ptr for their storage. Although it has been a while since I worked with C++11, maybe something prevents you from avoid that.
This project had changes since this issue was reported. It's a tiny change that doesn't warrant a PR. Is anyone gonna fix it or are you just gonna leave the responsibility of it on your users?
With this instruction set the MSVC emits unconditional usage of the instructions
vpxor
andvmovdqu
when constructing astd::shared_ptr
. On older CPU models that don't support the AVX instruction set this will result in a crash. It was quite frustrating to figure this out given that less than 1% of my users appear to be affected. Maybe this instruction set could not be unconditionally applied to libnyquist when built from CMake? Or maybe the usage ofstd::shared_ptr
can be reduced. Given that all decoders are stateless and 1-byte large there's next to not good reason to usestd::shared_ptr
for their storage. Although it has been a while since I worked with C++11, maybe something prevents you from avoid that.