bug report (complete)

[Tom 7]

Sorry -- that last mail was sent prematurely! Here it is again.

---------------------------------------------------

I love the new version; it's really fast!

The new compiler, I think, produces bad code for my MD5
implementation. (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tom7misc/net/mlftpd/md5.sml)
In particular, it raises Chr because the ints sent to 'chr' are huge, even
though they are protected with 'andb 0w255'. I whittled the code down to
this:

  fun wc hi lo = Word32.orb (Word32.<< (hi, 0w16),  lo)

  val chr = fn c =>
      let in
          print ("chr " ^ (Int.toString c) ^ "\n");
          chr c
      end

  fun w2b w =
      let in
          print ("w2B " ^ (Word32.toString w) ^ "\n");

          map chr
          [Word32.toInt (Word32.andb( w                 , 0w255)),
           Word32.toInt (Word32.andb(Word32.>>(w, 0w8)  , 0w255)),
           Word32.toInt (Word32.andb(Word32.>>(w, 0w16) , 0w255)),
           Word32.toInt (Word32.andb(Word32.>>(w, 0w24) , 0w255))]

          before print "success\n"
      end

  val _ = w2b (wc 0wx6754 0wx2301)


SML/NJ produces this result (which I think is correct):

w2B 67542301
chr 1
chr 35
chr 84
chr 103
success

MLton does this:
w2B 67542301
chr 1
chr 6771747
unhandled exception Chr


My intuition is that this is not a basis bug; some changes that should not
have had semantic significance in SML affected the behavior of the bug.


By the way, I downloaded the binary RPM and the source tgz, and tried to
compile the source with the binary, but it does this:

...
         numPeeks = 290571
         average position in bucket = 0.729
         size = 186261
         gcc -DNODEBUG -DMLton_safe=TRUE -DMLton_detectOverflow=TRUE \
             -I/usr/local/lib/mlton/include -o /tmp/filehQdgTY \
             /tmp/fileTQdAjy.c -L/usr/local/lib/mlton/lib -lmlton -lm -lgmp
         /tmp/filehQdgTY /tmp/filej4dkHo
         infer starting
            unification starting
            unification finished in 2.81 + 1.24 (31% GC)
            finish infer starting
mmap failed
Command exited with non-zero status 1
15.77user 4.76system 0:23.69elapsed 86%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (2753major+241757minor)pagefaults 0swaps
make[1]: *** [mlton-compile] Error 1
make[1]: Leaving directory `/usr/src/mlton-20010706/src/mlton'
make: *** [/usr/src/mlton-20010706/src/mlton/mlton-compile] Error 2


Have you heard of this? Any workarounds? It might just be my crazy system,
but I figured you should know.


Thanks,

 Tom

[ Tom 7 : http://www.andrew.cmu.edu/~twm/ ]
[ Tom 7 : http://fonts.tom7.com/          ]