Repository navigation
BUG: Clipping code assumes alignment % itemsize == 0 #26341
Description
The clipping code contains lines like:
npy_intp is1 = steps[0] / sizeof(T), os1 = steps[3] / sizeof(T);
NumPy guarantees that ufunc data is aligned, but NumPy does not guarantee that alignment is equal to the itemsize. (in particularly, that is clearly not true for complex numbers)
As the quick fix: The code shouldn't use this pattern at all, I think.
But even if we ignore complex (because clipping and complex are weird), do platforms even guarantee that for the basic numerical types? Should code at least have a static_assert() or so if using such a pattern?
(xref gh-26280 because that is why I noticed)
Activity
pijyoi commentedon Apr 28, 2024
My understanding of the code in question is that it is only assuming that items are spaced in multiples of the itemsize. i.e.
steps[0] % sizeof(T) == 0If the starting pointer was aligned, then all subsequent accesses would also be aligned.
Does NumPy not provide those guarantees on entry to the clip function?
If not, it wouldn't even be safe to dereference elements on processors that don't allow misaligned access?
seberg commentedon Apr 28, 2024
No, it guarantees alignment, which is good enough for that. But alignment can be smaller than itemsize.
mhvk commentedon Apr 28, 2024
So the above code would also fail for
longdouble(assuming alignment on 8 byte boundaries).I agree we should avoid the pattern altogether, especially since for most other ufuncs, we explicitly keep the pointers and just add the step to it.
[-]BUG: Clipping code assumes `itemsize == alignment`[/-][+]BUG: Clipping code assumes `alignment % itemsize == 0`[/+]seberg commentedon May 6, 2024
Closing, the speedup PR included the fix.