[MLton] latest MLton segfault in gmp

[Matthew Fluet]

On Wed, Oct 14, 2009 at 6:30 PM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
> On Wed, Oct 14, 2009 at 11:56 PM, Matthew Fluet <matthew.fluet at gmail.com>
> wrote:
>> In the next subsection (p. 13), on aggregates and unions, it states:
>>
>>  An array uses the same alignment as its elements, except that a
>> local or global array variable of length at least 16 bytes or a C99
>> variable-length
>> array variable always has alignment of at least 16 bytes.
>
> I think by global/local arrays they mean arrays not in the heap but the data
> segment. (local = static int64_t foo[4];, global = extern int64_t foo[4];)
>
> At any rate, this sounds like we don't need to worry because MLton only
> passes arrays as pointers (both FFI and GMP limb structure).

Agreed.  I missed that it was "array *variable* of length at least 16
bytes", not any array (memory object).

>> I did want to also point out that there is a legacy issue, I would
>> assume, on Debian.  Since mlton-20070826 is dynamically linked against
>> libgmp, isn't it just an incredible luck of the draw that a
>> self-compile with mlton-20070826 didn't happen to produce a
>> non-16-byte aligned IntInf array.
>
> Yes, I was surprised too. However there are a couple reasons this worked
> out. First, the only code gcc managed to vectorize in the gmp C is the
> MPN_ZERO method. Second, the only place MPN_ZERO gets called (for us) is to
> clear the low bits of a left-shifted intinf. Third, it won't use 16-byte
> writes unless there are 16-bytes to write, so it had to be a >=128-bit left
> shift. I wonder if these maybe didn't happen in 20070826?

I'll bet it is r6253 (20071209):
  http://mlton.org/cgi-bin/viewsvn.cgi?rev=6253&view=rev
That limits constant folding to IntInfs in the range -2^128 -- 2^128,
and introduces an explicit calculation of 2^128 as IntInf.<<(1,0w128).