4 This chapter contains random notes (usually old emails) on various
7 \section{IntInf and Flattener
}
10 From: "Stephen T. Weeks" <sweeks@intertrust.com>
11 Date: Tue,
27 Jun
2000 18:
52:
19 -
0700 (PDT)
12 To: MLton@research.nj.nec.com
13 Subject: safe for space ... and IntInf
16 Your mail also came at a fortunate time, as I was trying to track down
17 a seg fault I was getting in the smith-normal-form regression test.
18 For stress testing, I turned off all the cps simplify passes (except
19 for poly equal) and ran the regressions. smith-normal-form failed
20 with a seg fault when compiled normally, and failed with an assertion
21 failure in
\verb+IntInf_do_neg+ when compiled -g. The assertion
22 failure was right at the beginning, checking that the frontier is in
25 assert(frontier == (pointer)&bp->limbs
[bp->card -
1]);
27 I'd been tracking this bug for a couple hours when I received your
28 mail about the flattener. Do you see the connection? :-) As a
29 reminder, here is the code for
\verb+bigNegate+
31 fun bigNegate (arg: bigInt): bigInt =
33 then let val argw = Prim.toWord arg
36 else Prim.fromWord (Word.- (
0w2, argw))
38 else Prim.~ (arg, allocate (
1 + bigSize arg))
40 The problem is, when the flattener is turned off, there is an
41 allocation in between the call to allocate and the
\verb+Prim.~+ call. The
42 argument tuple allocation screws everything up. So, we are relying on
43 the flattener for correctness of the IntInf implementation. Any ideas
44 on how to improve the implementation to remove this reliance, or at
45 least put an assert somewhere to avoid falling prey to this bug again?