The initial allocation for the slice is limited to prevent untrusted
data from forcing a huge allocation, but then the dynamic array was
created with a capacity of the unlimited length, rather than the actual
capacity of the allocation. This was causing a buffer overrun.
This can be important if matrices or SIMD vectors are being used in
global or static variables, as otherwise it may result in crashes due to
aligned instructions accessing misaligned variables.
The lower bound of the `bit_set` was only being applied *after*
searching for a matching enum value, so values wouldn't line up if the
minimum value of the enum wasn't 0.
The existing `mem.make_map` passes a capacity, but the builtin
`make_map` no longer takes a capacity--it was separated to
`make_map_cap` to allow for making a map without an allocation (#4340).
`core:mem` was not updated to reflect this, so any usage of `mem.make`
to make a map will currently result in a compile error.
Comparing SIMD vectors with `==` was checking that the mask of elements
that matched was not 0, meaning it succeeded if *any* element was equal,
rather than if *all* elements were equal.
This allows `*` to be used in C fashion, without specifying an argument
index to use. Like C, this results in the argument *preceding* the value
for the format specifier itself.
This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Translation matrices use the w components of the matrix to apply the
transform, and thus only work when the w component is 1. In the
original raymath implementation, the multiplication is done manually
and adds the translation components directly to the result, as if w is
1, but in the Odin binding this is done with a matrix multiplication.
However, the w component is set to 0 instead of 1, resulting in the
translation not being applied.
Removed underscores from the AVX-512 names in `CPU_Feature` to make them match their equivalent LLVM target features. Removed 4FMAPs and 4VNNIW as there aren't matching LLVM target features.
Barinzaya
