[MLton] latest MLton segfault in gmp

[Wesley W. Terpstra]

On Sun, Oct 11, 2009 at 3:59 PM, Matthew Fluet <mtf at cs.rit.edu> wrote:

> On Sat, 10 Oct 2009, Wesley W. Terpstra wrote:
>
>> On Sat, Oct 10, 2009 at 10:27 PM, Wesley W. Terpstra <wesley at terpstra.ca
>> >wrote:
>>
>>  I've tried compiling with -align 8 and then it works... I'm not sure this
>>> is a solution, though; it may have just masked the problem.
>>>
>>
>> Found the smoking gun! Debian builds gmp with -O3 whereas I used -O2 for
>> MinGW32. If you look at the assembler output of mpz/mul_exp.c with the two
>> options you will notice a difference... the introduction of a 'movdqa'
>> instruction, which is an SSE2 instruction that expects 16-byte alignment.
>>
> ...
>
>> What's the plan going forward? align(AMD64) == 8?
>>
>
> However, from what you have described, it doesn't seem as though defaulting
> to '-align 8' on amd64{-linux?} is sufficient.


No, 8 alignment is sufficient. That assembler from gcc assumes it was 8 byte
aligned and then promotes it to 16-byte alignment by testing the 3rd bit and
optionally doing a single 8-byte operation before moving on to 16-byte
operations.



> ... it won't guarantee that IntInf arrays are aligned on 16-byte boundaries


Unnecessary.

On the other hand, I don't see how the gmp.h header guarantees that a
> mp_limb_t* is 16-byte aligned.


It doesn't.


> It is simply a pointer to a 64-bit integer, so it seems that gcc can only
> assume that the allocated object pointed to by a mp_limb_t* is 8-byte
> aligned.


That's exactly what it assumes.


> Am I misunderstanding the assembly?  Is it dynamically checking the
> alignment and using the SSE2 instructions only if it happens to be 16-byte
> aligned?
>

It dynamically checks the alignment and does a single 8-byte operation if
necessary to move forward onto 16-byte aligned values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20091011/41ee349b/attachment.html