Ah, ok, that makes more sense. Yeah the SSE stuff requires aligned data. Looking into the test code, I can't figure out why it doesn't fail on Core2 with the current test code, which appears to be using all possible alignments. (I've just run it again for some time and it doesn't fail.)
I still haven't quite gotten to the bottom of it. There's also special test code written just for lshift, but it predates us, so I don't know yet what it does, let alone whether it is ever invoked. At the very least, if Jason intended limbs to be aligned, there is a bug in the documentation and in the make check test code, which should report a failure to the user in case they are using a non-standard allocator. However, I am leaning more towards the idea that Jason did not intend for this to be the behaviour and the test code is not doing what it says it is doing, i.e. it is just a code bug, but the test code is actually insufficient to detect it! Bill. 2009/12/10 Dan Grayson <d...@math.uiuc.edu>: > He could also mean that the machine instructions that move 8 byte > words to vector registers would segfault if you tried to use them on > nonaligned data, and that he tried to write mpn_lshift to try to avoid > doing that. Those are the lines of code I pointed to in the original > report. It would be a bug to write code that depended on alignment, > as I pointed out, unless you change the documentation about custom > memory allocators, which should not be done lightly. > > On Dec 10, 9:43 am, Bill Hart <goodwillh...@googlemail.com> wrote: >> I found the following in correspondence with Jason (I can't just ask >> him, as his internet seems to be offline at the moment): >> >> "Misaligned data will segfault on some arches and instructions eg K10 >> and lshift" >> >> So presumably he has assumed data is aligned on K10, written a fast >> version of the code for this case, then propagated it to other arches >> where no segfault will occur. Actually, I am unsure whether that is >> what he means, but that is what I infer. >> >> If so, the solution would seem to be to replace the Core2 and Atom >> code with a safer version and leave the K10 code as is. That's really >> something Jason should do though, so we probably have to wait for him >> to pop up again. > > -- > > You received this message because you are subscribed to the Google Groups > "mpir-devel" group. > To post to this group, send email to mpir-de...@googlegroups.com. > To unsubscribe from this group, send email to > mpir-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/mpir-devel?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
