-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
BUG: tighten alignment for complex types. #5365
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
type
are 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