It has been discovered that AddressSanitizer does not keep a 1:1 mapping
of which bytes are poisoned and which are not. This can cause issues for
allocations less than 8 bytes and where addresses straddle 8-byte
boundaries.
See the following link for more information:
https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#mapping
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction in different orders than sequential order. These alternative
orders can often offer better SIMD hardware utilization.
Two different orders are added: pair-wise (operating on pairs of
adjacent elements) or bisection-wise (operating element-wise on the
first and last N/2 elements of the vector).
allocators
This adds various bindings to the asan runtime which can be used
to poison/unpoison memory handed out by various allocators. This
means we can catch use after free memory bugs when using operations
such as free_all during runtime.
Asan poisoning are added for the follow allocators in mem:
Arena (including temporary arenas)
Scratch
Stack
Small_Stack
Additionally a bug in the stack allocator was fixed to disallow freeing
in the middle of the stack (caught by the asan!).
I plan on adding support for all the allocators in core. This is just
a good starting point and were some of the easiest ones to implement
asan for.
`typeid` used to be a fancy index with extra metadata stored on it. Now it is direct hash of the type.
This is safe to do in practice since any possible collisions are checked at compile time AND the chances of having a 1% collision are around 1 in 600K (see the Birthday Paradox).
Therefore accessing a `^Type_Info` is now a hash table lookup with linear probing. The table is twice the size than necessary so prevent too much probing due to an overly dense hash table.
Jon Lipstate
Feoramund
gingerBill
iarkn
Matteo
Jeroen van Rijn
0xrsp
gingerBill
Laytan Laats
Lucas Perlind
Barinzaya
Harold Brenes
Dave Voutila