BUG: tighten alignment for complex types.#5365
Conversation
Complex types memory representations in C are guaranteed to be equivalent to type[2]. As such, the alignment of complex<type> should be the same as type.
|
test failure is real, should be the same you see on sparc |
|
confirmed the bus error on sparc with this patch,, see I told you I tried this :) |
|
The real problem apparently is that the logic in the loop selection in |
|
yes thats why I introduced the copy alignment variable to account for this, one could also add special complex code or only use copy alignment for copy operations. |
|
Yes, the problem is that |
|
I won't finish it today (or tomorrow), but the suggested fix would be to restore |
|
do we really care that a complex float32 from 8 byte unaligned memory is not flagged as 4 byte aligned? |
|
I haven't worked on this so my opinion might be totally irrelevant, but if I understand correctly, it makes sense to distinguish the types of alignment if one is specific to the needs of copying. |
|
"do we really care that a complex float32 from unaligned memory is not Do I have it right that basically what the strided copy loop code should be
|
|
The strided copy loop should be doing |
|
1.8 didn't actually check the alignment, everything was aligned |
|
@juliantaylor: do you mean |
|
the former, but also for arrays which where created by passing the constructor a pointer |
|
@pv for numpy 1.8.1 on win-32, I had |
|
@cournape test failure for Bento build |
|
Closing this. For 1.9.2 will backport #5316, and for 1.10.0 another fix is pending. |
Complex types memory representations in C for a given
typeare guaranteed to be equivalent totype[2]. As such, the alignment ofcomplex<type>should be the same astype.I tested scipy 0.14.x (at scipy/scipy@d6c3206, containing the f2py workaround) in the following setups:
numpy 1.9.1, w/ this patch
numpy 1.9.1, w/o this patch