For compatibility with a Facebook internal project, clang now mangles
Objective-C types and C structures in the same way. This is a terrible
idea, but it apparently doesn't break anything.
This was triggered when upgrading ivars from the pre-2.0 ABI that used
long double - their alignment could not be calculated correctly and we
hit an assertion.
Fixes: #82
__builtin_clz takes an unsigned int, it isn't overloaded for different
types. This meant that we were computing log2 by counting the
leading bits in a 32-bit value and using that result as if it were the
number of bits in a 64-bit value. This meant that our alignment values
were 2^32 times as big as they should be. This mostly didn't matter,
because we then truncated the result to 32 bits and the wrapping gave
the correct answer.
Unfortunately, this was undefined behaviour and, at sufficiently high
optimisation levels, this resulted in the value being optimised away,
leading to odd results.
This change is effectively a no-op (it's impossible to throw an
exception through these trampolines, because they tail call the real
block), but it does prevent the linker from complaining that we're
linking SEH-aware and SEH-unaware code.
On 32-bit Windows, malloc doesn't give us memory with sufficiently
strong alignment for AVX vectors.
Note that Windows also has a family of allocators that provide guarantee
exact misalignment. Using these would simplify the ivar layout logic
slightly, because we wouldn't need to account for the refcount pointer.
It's not clear that it's actually worth doing though, because that logic
already exists.
We weren't correctly sign-extending the value being compared, which was
resulting in objects not being deallocated. For some reason, this only
appeared on Windows, even though the code looked wrong on all platforms.