Home My Page Projects Code Snippets Project Openings SML/NJ
Summary Activity Forums Tracker Lists Tasks Docs Surveys News SCM Files

SCM Repository

[smlnj] View of /bugs/branches/smlnj/bugs.1001-1200
ViewVC logotype

View of /bugs/branches/smlnj/bugs.1001-1200

Parent Directory Parent Directory | Revision Log Revision Log


Revision 945 - (download) (annotate)
Thu Oct 4 13:38:32 2001 UTC (17 years, 8 months ago)
File size: 286806 byte(s)
This commit was manufactured by cvs2svn to create branch 'smlnj'.
Number: 1001
Title: matching exn constructor against valspec fails
Keywords: signature matching, representation
Submitter: sestoft@research.att.com
Date:      3 April 1995
Version:   107.8 
System:    SGI MIPS
Severity:  Compiler bug
Problem:  

Matching an exception constructor against a valspec causes code in
cps/convert.sml to fail.

Code: 

    structure S : sig val e : exn end = struct exception e end;

Transcript: 

    Standard ML of New Jersey, Version 107.8, March 24, 1995 [new runtime]
    - structure S : sig val e : exn end = struct exception e end;
    The lvar 166 is not in the current hashtable!
    Error: Compiler bug: TypeInfo hash table in convert.sml

Comments:

The problem did not come up in `real code', but is a side effect of an
attempt to understand the implementation of signature matching.

The problem occurs also if the exception takes an argument.  Matching
a value constructor against a valspec works.  Both cases were OK in
0.93.

Fix:

The problem is probably in signature matching (trimmings), in
representation analysis, or in their interaction.

[Zhong Shao:] The problem is that signature matching didn't generate
the correct thinning function when an exception is matched against a
val spec.

The above bug is now fixed by slightly changing the "modules/sigmatch.sml" 
file (based on the version in 107.8). [New sigmatch.sml file supplied.]

Owner: Zhong
Status: fixed in 107.8+ [dbm]
----------------------------------------------------------------------
Number: 1002
Title: reappearance of various abstype bugs
Keywords: abstype
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           4/3/95
Version:        1.07
System:         any
Severity:       major
Problem:        reappearance of various abstype bugs
Code:

	fun foo x = let abstype t1 = T | F with val goo = foo end in goo x end
and,
	abstype 'a foo = Foo of 'a list with fun test x = (x = Foo []) end

Transcript:     

(* see 72, 311, 317 *)
    
    - abstype 'a foo = Foo of 'a list with fun test x = (x = Foo []) end;
    147-159 Error: operator and operand don't agree (equality type required)
      operator domain: ''Z * ''Z
      operand:         ''Z * 'Y foo
      in expression:
        = (x,Foo nil)
    type 'a foo
    val test = fn : ''a -> _
    - val a = test 3;
    val a = - : 'a
    - a a;
    Bus Error
    
    Process Inferior eXene exited abnormally with code 138

(* see 936 (middle example, Compiler bug: CoreInfo.coreLty3) *)
    
    - fun foo x = let abstype t1 = T | F with val goo = foo end in goo x end;
    The lvar 139685 is not in the current hashtable!
    Error: Compiler bug: TypeInfo hash table in convert.sml
    
Comments: (these are on the 72/311/317 variant *)

   + according to 311, this should compile; but perhaps 317
     indicates that it should not.  i would expect abstypes to
     behave like datatypes inside the "with".  so Foo would be
     an eqtype inside, and abstract outside;  but 317 shows how
     Foo being an eqtype inside could leak out.
   + note how, despite the error, it is compiled w/ bogus type ''a -> _
     (and hence one can crash the machine)
   + also note the odd location: 147-159, instead of something
     like std_in:147.0-147.60

Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1003
Title: extra newline in non-exhaustive match warning
Keywords: error message, printing
Submitter:      Thomas Yan (tyan@cs.cornell.edu)
Date:           4/3/95
Version:        1.07
System:         all
Severity:       minor
Problem:        extra newline in non-exhaustive match warning
Transcript:	(* note lack of extra newline for non-exhaustive binding *)
		- val 1 = 1;
		std_in:65.1-65.9 Warning: binding not exhaustive
		          (1 : int) = ...
		- fn 1 => 2;
		std_in:0.0-0.0 Warning: match nonexhaustive
		          (1 : int) => ...
		  
		val it = fn : int -> int
Comments:	this can create an annoying additional 50% (3 lines
		instead of 2) of warning messages
Fix:		this is untested, but i think this will work,
		since bindPrint does not print a trailing newline.
		replace matchPrint in mc.sml by:

      fun matchPrint (env,rules,unused) = fn ppstrm => let
	    fun matchPrint' ([],_,_) = () (* can this happen? *)
	      | matchPrint' ([_],_,_) = () (* never print last rule *)
	      | matchPrint' (rules,tags,i) = if null tags orelse i <> hd tags
		  then matchPrint''("        ",rules,tags,i)
		  else matchPrint''("  -->   ",rules,tl tags,i)
	    and matchPrint''(pre,(pat,_)::more,tags,i) =
		  (if i>0 then add_newline ppstrm else ();
		   add_string ppstrm pre;
		   PPAbsyn.ppPat env ppstrm (pat,!printDepth);
		   add_string ppstrm " => ...";
		   matchPrint'(more,tags,i+1))
	    in add_newline ppstrm;
	       begin_block ppstrm CONSISTENT 0;
	       matchPrint'(rules,unused,0);
	       end_block ppstrm
	    end

Owner:
Status: open
----------------------------------------------------------------------
Number: 1004
Title: blastIn and blastOut fail on objects containing code
Keywords: I/O, blastIn, blastOut
Submitter: Peter Bailey (Peter.Bailey@cs.anu.edu.au)
Date: 4/5/95
Version: 107
Severity: major
Problem: blastIn and blastOut fail on objects containing code
Comments:
  [JHR:] I didn't implement this feature as a way to save time, but it
  shouldn't be too much trouble.  I'll try to find some time to fix this
  soon (before the next official release).
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1005
Title: selecting an integer component from arg to C function
Keywords: C
Submitter: Peter Bailey (Peter.Bailey@cs.anu.edu.au)
Date: 4/5/95
Version: 107
Severity: major
Problem: 
  When you call a C function from ML, and are selecting an integer
  component from the argument that is passed (ie. with REC_SELINT ...)
  the INT_MLtoC conversion that is applied fails when the ML integer
  was negative. The code of INT_MLtoC just performs a right shift (>>)
  of the value to undo the boxing representation, and this works fine
  for positive numbers, but fails for negative numbers, give a result
  (on a SPARC running SunOS 4.1.3 with gcc as the compiler) of (2^31)-1.
  I checked through the list of C functions that exist at the moment
  in the C libraries, and all of them that require integers in their
  arguments would be expecting non-negative integers.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1006
Title: BitArray.sub raises Ord rather than Subscript
Keywords: BitArray, exception
Submitter: 		Guhan Viswanathan (gviswana@cs.wisc.edu)
Date: 			3/12/95
System(s) and Version:	Library (0.3)
SML/NJ Version: 	1.03f
Machine: 		SparcStation, SunOS 4.1.3
Severity: 		Minor
Problem: 		BitArray.sub raises Ord rather than Subscript
Transcript:

- structure BA = BitArray;
structure BA : BIT_ARRAY
- val b = BA.bitarray 5;
val b = BA {bits=-,nbits=5} : BitArray.bitarray
- BA.sub(b, 6);
uncaught exception Ord

Comments: Also happens with setBit, clrBit
Owner:
Status: obsolete - old basis
----------------------------------------------------------------------
Number: 1007
Title: Compiler bug: applyTyfun: not enough arguments (no functor)
Keywords: signature matching
Submitter: Robert Findler (Robert_Findler@INBOX.FOX.CS.CMU.EDU)
Date: 3/13/95
Version: 107.7
Severity: major
Problem: Compiler bug: applyTyfun: not enough arguments
Code:

structure S : sig type 'a t = 'a end = struct type 'a t = 'a end;

Comments: see 932, 964.  This example doesn't use a functor.
Owner:
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 1008
Title: makeml uses "rm -f" on a directory
Keywords: makeml
Submitter: 		La Monte H. Yarroll <piggy@baqaqi.chi.il.us>
Date: 			Mon Feb 21 16:46:58 DST 1994
System(s) and Version:	SML/NJ 0.93 compiler
SML/NJ Version: 	0.93
Machine: 		SparcStation, SunOS 4.1.3
Severity: 		minor
Problem: 		makeml uses "rm -f" on a directory
Code:
from src/makeml:
...
    echo "$CMD rm -f mo"
    rm -f mo
...
    echo "$CMD rm -f mo"
    rm -f mo
    (cd $RUNTIME; eval make clean; rm -f mo)
fi

exit 0

Transcript: 		(Made up transcript...)

# rm -f mo
# fsck /dev/sd01
Unreferenced inode 294, reattach? (y/n) 
etc...

Comments:
Certain simple-minded operating systems (e.g. COHERENT) implement rm
as a simple unlink.  On these systems, an ordinary user is prevented
from removing a directory.  The user must use the setuid program
"rmdir" which checks to make certain that the directory is empty
before removing it.

If you do not provide the -r (recurse) flag to rm, it will NOT
recurse.  The -f flag (force) tells rm to try to remove even if it
doesn't think it's a good idea.  SO, "rm -f dir" will cause the link
to "dir" to be removed, usually leaving an inconsistant filesystem,
(unless there happens to be another hard link pointing at that
directory tree).

If you are going to remove whole directory trees, it is a REALLY good
idea to use "rm -rf dir".

Not many systems use V7-style filesystems any more, but the fix is
harmless on modern filesystems, and saves headaches on the older
systems.

Fix:

use "rm -rf" instead of "rm -f" throughout makeml.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1009
Title: The Makefile for 1.02 assumes that you have . in your PATH
Keywords: configuration, installation
Submitter: 		La Monte H. Yarroll <piggy@baqaqi.chi.il.us>
Date: 			Fri Apr 29 15:40:08 EST 1994
System(s) and Version:	SML/NJ 1.02 compiler
SML/NJ Version: 	1.02
Machine: 		SparcStation, SunOS 4.1.3
Severity: 		minor
Problem: 		The Makefile for 1.02 assumes that you
			have . in your PATH.
Fix:
It is safe to explicitly add ./ everywhere it's needed.

# arguments:
#   OS =  the SML/NJ operating system name (eg, mach)
#   MACHINE = the SML/NJ machine name (eg, decstation)
#   FLAGS = miscellaneous flag options (eg, -gcc)
#   SOFTLIMIT = the softlimit (-m) argument to makeml (eg, 7000)
# See doc/release-notes/releaseNotes.{dvi,ps,txt} for information
# on how to set these parameters.
SOFTLIMIT = 7000
most: sml-export sml mllex mlyacc sml-tags sml-conn smlsg
sml-export:
	./makeml -$(MACHINE) $(OS) $(FLAGS) -m $(SOFTLIMIT) -noshare
	mv sml sml-export
sml: sml-export
	./makeml -$(MACHINE) $(OS) $(FLAGS) -m $(SOFTLIMIT) -noclean
mlyacc: sml-export
	(cd ../tools/mlyacc; make ec; make stand-alone)
	cat ../tools/mlyacc/smlyacc.sml | ./sml-export
mllex: sml-export
	cat ../tools/lexgen/lexgen.sml ../tools/lexgen/export-lex.sml \
	  | ./sml-export
sml-tags: sml-export
	cat ../tools/gnutags/export.sml | ./sml-export
sml-conn: sml-export
	cat ../tools/sourcegroup/sml-conn/export.sml | ./sml-export
smld: sml-export
	./makeml -$(MACHINE) $(OS) $(FLAGS) -m $(SOFTLIMIT) -debug -noclean
smlsg: sml
	cat ../tools/sourcegroup/export.sml | ./sml

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1010
Title: Compiler bug tripped by type abbreviations
Keywords: type abbreviation, signature
Submitter:      Emden R. Gansner, erg@research.att.com
Date:           11/26/1994
Version:        1.06
System:         Probably all
Severity:       minor
Problem:        Compiler bug tripped by type abbreviations.
Code:
Transcript:
  Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime]
  - signature s = sig
  =  type 'a list_item = string * 'a
  = end;
Error: Compiler bug: Misc.checkbound
Owner:
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 1011
Title: mod operator causes core dump on Alpha
Keywords: mod, arithmetic
Submitter: Yizhong Zhou <zhou@puffin.usmcs.maine.edu>
Date: 1/26/95
Version: 106
System: Alpha, OSF/1 1.2
Severity: major
Problem: 
  Whenever I used mod operator in an expression, the SML aborted with the message

     sml/bin/.run/run.alpha32-osf1: Fatal error -- unexpected fault, 
     signal = 8, code = 0x10" message
Comment: [Blume, 3/18/97]
  bug 1011 is still there: the expression (5 mod 0) or (5 div 0) crashes
  sml on the Alpha32x:

    $ uname -a
    OSF1 dynamic V3.2 17 alpha
    $ bin/sml-cm
    Standard ML of New Jersey, Version 109.25.2, March 3, 1997 [CM; autoload enabled]
    - 5 mod 0;
    /u/blume/Research/ML/9.25.2/bin/.run/run.alpha32x-osf1: Fatal error -- unexpected fault, signal = 8, code = 0xc

Comment: [Lal, 3/21/97]
  [This] is fixed. I have tested the fix on both Digital Unix and OSF/1
  v3.2. 

  The problem was that division is being done in floating point
  registers, and floating point divide-by-zero is supposed to return
  inf. The only reliable mechanism to generate an integer divide-by-zero
  trap is to use a call_pal instruction with a gentrap function code. 

  I therefore test for zero explicitly in the generated code and branch
  to a shared and off-line piece of code that sets up the pal call.

  There is a small change required to the runtime system. Signal
  handling under Digital Unix is still screwed up. The machine ucontext
  is not being passed correctly to the signal handler.

Owner: Lal
Status: fixed in 109.26 [Lal]
----------------------------------------------------------------------
Number: 1012
Title: Word32.wordToInt and Word32.signExtend raise Overflow
Keywords: conversion, word
Submitter:              esb@cs.cmu.edu
Date:                   Fri Mar 24 10:34:15 EST 1995
System(s) and Version:  SML-SCB (compiler)
SML/NJ Version:         107.0
Machine:                Mips only
Severity:               minor
Problem:                Word32.wordToInt and Word32.signExtend raise Overflow
			for some values (generally, high bit set)
Code/Transcript:                   
- val (low, high) = (Word32.intToWord 0xde32, Word32.intToWord 0x8002);
val high = 32770 : Word32.word
val low = 56882 : Word32.word
- val x = Word32.orb (Word32.shift (high, 16), low);
val x = 2147671602 : Word32.word
- Word32.wordToInt x;

uncaught exception Overflow
- Word32.signExtend x;

uncaught exception Overflow

Comments:		Works fine on the alpha

  As of Sept 3, 1997 the Status was "fixed in 109.21", but
  in fact this is not a bug, Overflow should be raised in both cases.
			-- Andrew

Owner: John
Status: not a bug
----------------------------------------------------------------------
Number: 1013
Title: types from included signature
Keywords: include, signature
Submitter:              Edo Biagioni, esb@cs.cmu.edu
Date:                   August 15, 1995
System(s) and Version:  Compiler
SML/NJ Version:         108.3, June 5, 1995 [CM&CMB 1].  Also 108.8
Machine:                Alpha OSF 2.0
Severity:               headache (somewhere between minor and major)
Problem:                Including signatures do not correctly inherit
			type sharing from included signatures.

Transcript:
edo@apl 6-> sml
loading /afs/cs.cmu.edu/project/fox-8/member/cline/port/108.3/bin/.heap/sml-ful
> l
-cm.alpha32 ......................... done
Standard ML of New Jersey, Version 108.3, June 5, 1995 [CM&CMB 1]
val it = () : unit
- use "test.sml";
[opening test.sml]
signature A =
  sig

...

      con D : {extension:x} -> d
    type t
    type b_x
    sharing type x = b_x
  end
Error: Compiler bug: tycon_eqprop: RELtyc
-

Comments:               
This may be the same as previously submitted module-system bugs, but it
looks different.  It seems to have at least two different
manifestations, one being that an object of type In.x simply won't
unify with one of type In.b_x.  To see this, simply change the type
of field "a" in b_x to be "bool" instead of "t", i.e.
	type b_x = {a: bool, b: int}
The result is:
test.sml:24.12-24.43 Error: case object and rules don't agree (tycon mismatch)
  rule domain: In.b_x
  object:      In.x
  in expression:
    (case extension
      of {a=a,...} : In.b_x => {1=a})

Code:
signature A =
 sig
  type x
  datatype d = D of {extension: x}
 end

signature B =
 sig
  include A
  type t
  type b_x = {a: t, b: int}
  sharing type b_x = x
 end

signature C =
 sig
  include B
 end;

functor F (structure In: C) =
 struct
  fun f arg =
       let val In.D {extension} = arg
           val {a, ...}: In.b_x = extension
       in a
       end
 end

Comment: [dbm] now produces "uncaught exception Unbound" indicating a
  probable out of order instantiation problem.

Test: bug1013.sml
Owner: dbm
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1014
Title: Compiler bug: Instantiate: simplify
Keywords: instantiate, signature, modules
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			02/25/96
System(s) and Version:	Compiler
SML/NJ Version: 	109.4
Machine: 		probably all
Severity: 		major
Problem: 		Compiler bug: Instantiate: simplify
Code:			

Transcript: 		

Standard ML of New Jersey, Version 109.4, February 21, 1996 [CM&CMB 1]
GC #0.0.0.0.1.5:   (20 ms)
val it = () : unit
- signature SIG = sig type t sharing type t = unit end;
signature SIG =
  sig
    type t
    sharing type t = unit
  end
- functor F(S : SIG) = struct end;
Error: Compiler bug: Instantiate: simplify
- functor F(type t sharing type t = unit) = struct end;
Error: Compiler bug: Instantiate: simplify

Owner: dbm
Status: fixed in 109.20
----------------------------------------------------------------------
Number: 1015
Title: formatting of real numbers is broken
Keywords: printing, real
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			12/01/95
System(s) and Version:	Compiler
SML/NJ Version: 	108.16
Machine: 		all
Severity: 		minor
Problem: 		formatting of real numbers is broken
Code:
Transcript:

Script started on Fri Dec 01 14:25:40 1995
sen14_1_sml
Standard ML of New Jersey, Version 108.16, November 23, 1995 [CM&CMB 1]
val it = () : unit
- 0.3;
val it = 03 : real
- 1.0;
val it = 1 : real
- 1E~6;
val it = 1e~06 : real

Comments:

The first problem is that the "." separating the fraction from the
integer part is lost.
The second problem is one of design. Should real numbers be output
in a "nice" format or a "useful" format? As it stands now, the output
(a) omits zero fractions, i.e. ".0", and (b) uses a lower-case "e" for
exponents. This makes the output illegal as Standard ML input.

The first problem was caused by using the wrong variable name in
(sml-nj/boot/real-format.sml)realToGenStr: "num" should have been "frac".

Fix:
*** sml-nj/boot/real-format.sml.~1~	Mon Nov 27 20:08:46 1995
--- sml-nj/boot/real-format.sml	Fri Dec  1 14:32:10 1995
***************
*** 206,218 ****
  
      fun realToGenStr prec r = let
  	  val {sign, whole, frac, exp} = realGFormat(r, prec)
! 	  val expStr = (case exp
! 		 of NONE => ""
! 		  | (SOME e) => if I.<(e, 0)
! 		      then "e~" ^ zeroLPad(atoi(I.~ e), 2)
! 		      else "e" ^ zeroLPad(atoi e, 2)
  		(* end case *))
- 	  val num = if (frac = "") then "" else ("." ^ frac)
  	  in
  	    concat[sign, whole, frac, expStr]
  	  end
--- 206,221 ----
  
      fun realToGenStr prec r = let
  	  val {sign, whole, frac, exp} = realGFormat(r, prec)
! 	  val (frac,expStr) = (case exp
! 		 of NONE => ((if (frac = "") then ".0" else ("." ^ frac)), "")
! 		  | (SOME e) =>
! 		      let val expStr = if I.<(e, 0)
! 					 then "E~" ^ zeroLPad(atoi(I.~ e), 2)
! 					 else "E" ^ zeroLPad(atoi e, 2)
! 		      in
! 			((if (frac = "") then "" else ("." ^ frac)), expStr)
! 		      end
  		(* end case *))
  	  in
  	    concat[sign, whole, frac, expStr]
  	  end

Comment [jhr]
  The missing decimal point has already been fixed.
  The question about ".0", I'll have to think about, since it ties into
  the new basis's definition of Real.toString.  I think it is likely that
  the syntax of real literals will be liberalized to include "e".

 [jhr, 5/20/97]
  The first two cases have been fixed.  The third case is no longer
  a bug in printing, but is a bug in the SML/NJ scanner:

  - 1E~6;
  val it = 1e~06 : real
  - 1e~06;
  stdIn:16.2 Error: unbound variable or constructor: e
  stdIn:16.1-16.6 Error: operator is not a function [literal]
    operator: int
    in expression:
      (1 : int) <ERRORvar>
 [dbm, 7/13/97]
  All cases are cleared up in 109.29+.
Owner: John
Status: fixed in 109.28
----------------------------------------------------------------------
Number: 1016
Title: datatype representation conflict
Keywords: datatype, signature, signature matching
Submitter: Andrew Appel
Date: 2/24/1994
Version: ?
System: ?
Severity: Major 
Problem: datatype representation conflict when spec and def are identical
Transcript:
  - signature S = sig type t = int * int datatype a = J of t | K of int end;
  signature S =
    sig
      type t
      datatype a
	con J : t -> a
	con K : int -> a
    end
  - structure H : S = struct  type t = int * int datatype a = J of t | K of int en
  d;
  std_in:9.11-9.79 Error: The constructor J of datatype a
  has different representations in the signature and the structure.
  Change the definition of the types carried by the constructors in the
  functor formal parameter and the functor actual parameter so that
  they are both abstract, or so that neither is abstract.

Test: bug1016.sml
Owner: Zhong
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1017
Title: another hard-to-read error message
Keywords: error message, type checking
Submitter: John Reppy
Date: 9/17/94
Version: ?
Severity: minor
Problem: another hard-to-read error message
Transcript:
  effective-pause.sml:159.13-190.7 Error: operator and operand don't agree (tycon mismatch)
    operator domain: {baseName:string, label:string, outFile:string, yMax:real}
		     * {baseName:string, label:string, outFile:string, yMax:real}
			 list
    operand:         {baseName:string, label:string, outFile:string, yMax:real}
		     * {baseName:string, label:string, outfile:string, yMax:real}
			 list
Comment:
If you stare at it long enough, you see that one "outfile" should be "outFile".
We reallyn need to have more precise messages for mismatches of record/tuple
types.
Owner:
Status: open
----------------------------------------------------------------------
Number: 1018
Title: subtraction from smallest int doesn't raise Overflow
Keywords: arithmetic, bounds, overflow
Submitter: Lorenz Huelsbergen
Date: 12/4/95
Version: 108.16
Severity: Major
Problem: subtraction from smallest int doesn't raise Overflow
Transcript:
- val x = ~1073741824;
val x = ~1073741824 : int
- x - 1;
val it = 1073741823 : int
Comments: subtraction should raise Overflow
Fix:
The problem is the line

  fun subt (Immed xi,y,z) 	      = add(y,Immed (~xi),z)

in mips.sml which I think should be:

  fun subt (Immed xi,y,z) 	      = addt(y,Immed (~xi),z)
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1019
Title: floats and Word32 in same closure
Keywords: float, real, Word32
Submitter:      Emden R. Gansner (erg@research.att.com)
Date:           8 December 1995
Version:        108.17 (& 109.19)
System:         irix5/sgi
Severity:       minor
Problem:        trips unimplemented feature
Code:
  fun loop (0, ws, rs) = ()
    | loop (n, ws, rs) = app print [Word32.toString ws, Real.toString rs];
Transcript:
  Error: Compiler bug: unimplemented int32 + float (nclosure.2)
Comments: [Zhong Shao, 12/9/95]
The current version of the compiler does not support putting
both floats and word32 into the same closure. It's on my to-do list,
and this will be supported very soon.
Test: bug1019.sml
Owner: Zhong
Status: fixed in 109.28 [Zhong, 4/30/97]
----------------------------------------------------------------------
Number: 1020
Title: type definitions in signatures not printed by top level
Keywords: printing, signatures, type abbreviations
Submitter: Bob Harper
Date: 12/11/95
Version: 108.16 - 109.19
Severity: medium
Problem: type definitions in signatures not printed by top level
Code: 
Transcript:
  - signature S = sig type t=int->int val x:t end;
  signature S =
  sig
    type t     (* definition got lost *)
    val x : t
  end
  - 
Test: bug1020.sml
Owner: dbm
Status: fixed in 109.19m [dbm, 11/15/96]
----------------------------------------------------------------------
Number: 1021
Title: StringCft.atof doesn't handle large numbers properly
Keywords: conversion, bounds
Submitter: 		David Gladstein (daveg@amnh.org)
Date: 			12/11/95
System(s) and Version:	library 0.2
SML/NJ Version: 	0.93
Machine: 		HPPA
Severity: 		minor
Problem: 		StringCft.atof doesn't handle large numbers properly
Transcript: 		
  - StringCvt.atof "300000000000000.000000";
  val it = 829341696.0 : real
  - 
Comment: It crashes on the unsupported Linux port.
Comment: [Reppy, 12/13/95]
The basic conversions have been moved into the Standard Basis.  In our latest
version, this example is not a problem:

  Standard ML of New Jersey, Version 108.18, December 11, 1996 [new runtime]
  - Real.fromString "300000000000000.000000";
  val it = SOME 3e14 : real option
Owner:
Status: fixed in 108.18 (on SGI/IRIX)
----------------------------------------------------------------------
Number: 1022
Title: image files grow
Keywords: performance, memory
Submitter: Tobias Nipkow <nipkow@sunbroy14.informatik.tu-muenchen.de>
Date: 12/13/95
Version: ?
Severity: minor
Problem:
If I repeatedly load a fixed ML-file of the form

  structure S = struct end;
  open S;

and export the result using exportML, the size of the created binary will be
proportional to the number of times I loaded the source file. This looks like
a bug to me. Note that there is no problem if the line "open S" is missing.
Comments: [Appel, 12/15/95]
Well, this is a bug, more or less.  It's not a trivial bug to fix, however.
The best solution is to use the Compilation Manager (available with
version 108.x for any x) for your edit-compile-debug cycle, and avoid
this top-level-interactive-loop problem entirely.

We may or may not be able to fix this bug in the long run for the
top-level interactive loop.
Owner:
Status: obsolete (or fixed?) [dbm]
----------------------------------------------------------------------
Number: 1023
Title: Array.extract over zero length arrays.
Keywords: 
Submitter:      Lal George
Date:		1/6/96
Version:	108.21
System:         all
Severity:       major
Problem:        Array.extract over zero length arrays.
Code:           
	fun a2v a = Array.extract(a, 0, NONE);
	val a0 : int Array.array = Array.fromList [];
	a2v a0;

Transcript:   

	- fun a2v a = Array.extract(a, 0, NONE);
	val a2v = fn : 'a array -> 'a vector
	-       val a0 : int Array.array = Array.fromList [];
	val a0 = [||] : int array
	-  a2v a0;
	Bus error

Comments:
	The problem is in Array.extract. A special case needs to
	be inserted for when the array is of zero length to begin
	with.
Owner:
Status: fixed in 109.19 (on mipseb-irix)
----------------------------------------------------------------------
Number: 1024
Title: unsound typing
Keywords: type checking
Submitter: Kenneth Cline & Bob Harper (ken.cline@CS.cmu.edu, rwh@CS.cmu.edu)
Date: 1/8/96
Version: 108.18
Severity: Extreme
Problem: bad type generalization leads to unsound typing
Transcript:
    - fun f x = let fun g y = (x, y) in (g 4, g"4") end;
    val f = fn : 'a -> ('b * int) * ('b * string)
Comments:
The type of the resule should have 'a instead of 'b in both places:

                 'a -> ('a * int) * ('a * string)

This breaks the soundness of the language, and should be fixed as soon
as possible.

Comment [dbm]: this bug is caused by the function MTDeriv.mtderivDec
called by Compile.elaborate (build/compile.sml).  This function specializes
polymorphic functions.

Test: bug1024.sml
Owner: Zhong
Status: fixed in 109.22 [109.19m]
----------------------------------------------------------------------
Number: 1025
Title: flakey array of Word32.word
Keywords: Word32, array
Submitter: Lorenz Huelsbergen
Date: 1/18/96
Version: 108.21
System: mipseb-irix, x86-linux
Severity: major
Problem: flakey array of Word32.word
Transcript:
  Standard ML of New Jersey, Version 108.21, January 15, 1996 [CM&CMB 1]
  val it = () : unit
  - val a = Array.array(1,0w0:Word32.word);
  val a = [|0wx0|] : Word32.word array
  - Array.update(a,0,0w1);
  val it = () : unit
  - Array.sub(a,0);
  val it = 0wx1 : Word32.word
  - Array.sub(a,0);
  val it = 0wx4aaadc : Word32.word
  - Array.sub(a,0);
  val it = 0wx4aaadc : Word32.word
  - Array.sub(a,0);
  val it = 0wx4abb40 : Word32.word
  - Array.sub(a,0);
  val it = 0wx4a6cc4 : Word32.word
  -
Owner:
Status: fixed in 109.19 (on mipseb-irix)
----------------------------------------------------------------------
Number: 1026
Title: Posix.FileSys.access returns false incorrectly
Keywords: Posix, files
Submitter: John Reppy
Date: 1/19/96
Version: 108.21
System: ?
Severity: major
Problem: 
Posix.FileSys.access returns false on executable files when the file in not
owned by the user running ML.
Transcript:
  <jhr@radish> ls -l /bin/bc
  -rwxr-xr-x    1 root     daemon     35584 Apr 12  1994 /bin/bc*
  <jhr@radish> ls -l bin/sgmls.sh
  -rwxr-xr-x    1 jhr      jhr          185 Jan 15 14:25 bin/sgmls.sh*
  <jhr@radish> /usr/local/sml/108.21/bin/sml
  Standard ML of New Jersey, Version 108.21, January 15, 1996 [CM&CMB 1]
  val it = () : unit
  - Posix.FileSys.access("/bin/bc", []);
  val it = true : bool
  - Posix.FileSys.access("/bin/bc", [Posix.FileSys.A_EXEC]);
  val it = false : bool
  - Posix.FileSys.access("bin/sgmls.sh", [Posix.FileSys.A_EXEC]);
  val it = true : bool
  -
Comments:
In 108.5, OS.FileSys.access worked, but it was a separate implementation.
In 108.21, OS.FileSys.access and Posix.FileSys.access share an implementation.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1027
Title: Word32.fromString and Word.fromString broken
Keywords: Word32, conversion
Submitter: Lorenz Huelsbergen
Date: 1/22/96
Version: 109 - 109.19
System: sparc-sunos, x86-linux, mipseb-irix
Severity: major
Problem: On sparc and x86 (at least), Word32.fromString (and Word.fromString)
are broken.
Transcript:
  : arran 152; sml-cm
  Standard ML of New Jersey, Version 109, January 19, 1996 [CM&CMB 1]
  val it = () : unit
  - Word32.fromString "0wx2";
  val it = SOME 0wx0 : Word32.word option
  - Word.fromString "0w2";
  val it = SOME 0wx0 : word option

Comment: [jhr, 1/23/96]
Actually, I think the problem is that we are not yet handling the "0w" prefix.
When I implemented this, the SMLSL specified that these functions did not
process the prefix, so they are just converting the "0".  Since then, the
SMLSL specification has changed, but not the implementation.

Owner: jhr
Status: fixed in 109.27 [jhr, 4/11/97]
----------------------------------------------------------------------
Number: 1028
Title: Char.toString does not escape the backslash character
Keywords: conversion, string
Submitter:      Emden R. Gansner (erg@research.att.com)
Date:           25 January 1996
Version:        109
System:         all
Severity:       minor
Problem:        Char.toString does not escape the backslash character
Code:
Transcript:
- Char.toString #"\\";
val it = "\\" : string
Comments:
Should return "\\\\"
Owner:
Status: fixed in 109.19 (mipseb-irix)
----------------------------------------------------------------------
Number: 1029
Title: use not finding file on x86-solaris
Keywords: use, files
Submitter: Norman Ramsey
Date: 1/12/96
Version: 108.19
System: x86-solaris
Severity: major
Problem: use not finding file on x86-solaris
Transcript:
Here are the results of two compilations of the same source, one
on sparc-sunOS, and one in x86-Solaris:

: nr@labrador 94 ; /p/sml-108.19/sml
Standard ML of New Jersey, Version 108.19, December 24, 1995 [CM&CMB 1]
val it = () : unit
- use "scheme.sml";
[opening scheme.sml]
GC #0.0.0.0.1.7:   (10 ms)
GC #0.0.0.1.2.21:   (110 ms)
scheme.sml:209.62-209.82 Error: operator and operand don't agree (tycon mismatch)
  operator domain: string * string
  operand:         string * {cause:exn, function:string, name:string}
  in expression:
    ^ ("I/O error: ",msg)
scheme.sml:216.69-216.89 Error: operator and operand don't agree (tycon mismatch)
  operator domain: string * string
  operand:         string * {cause:exn, function:string, name:string}
  in expression:
    ^ ("I/O error: ",msg)
- 


: nr@xinu3 25 ; /p/sml-108.19/sml
Standard ML of New Jersey, Version 108.19, December 24, 1995 [CM&CMB 1]
val it = () : unit
- exportFn;
val it = fn : string * (string * string list -> ?.OS_Process.status) -> 'a
- use "scheme.sml";
[opening scheme.sml]

uncaught exception SysErr: No such file or directory [<OS.errorName unimplemented>]
  raised at: build/interact.sml:57.10
             build/computil.sml:40.41
             build/compile.sml:209.8
             util/stats.sml:168.40
             build/evalloop.sml:193.62

Comment: [jhr, 4/3/97]
  I this was either not a bug, or it has been fixed.  I'm not able
  to reproduce it on our x86/solaris machine.
Owner: jhr
Status: not reproducible
----------------------------------------------------------------------
Number: 1030
Title: string literals in presence of CM-library on Alpha
Keywords: string, literal
Submitter: Andrew Appel <appel@CS.Princeton.EDU>
Date: 1/30/96
Version: 109
System: alpha-aix, not hppa
Severity: major
Problem: string literals not handled properly
Code:
Source files:

sources.cm:
Group is
toy.lex.sml
/u/appel/ml/109/lib/smlnj-lib.cm

toy.lex.sml:
structure Lex = struct
val s5 =
"\105\105\105\105\105\105\105\105\105\105\119\105\105\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105\105\118\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\106\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\105\
\\105"
fun sum s = foldr op + 0 (map ord (explode s))

val _ = (print (sum s5); print "\n")
end
Transcript:
alpha% sml
Standard ML of New Jersey, Version 109, January 19, 1996 [CM&CMB 1]
val it = () : unit
- CM.make();
[starting dependency analysis]
[scanning sources.cm]
[checking .alpha32/sources.cm.stable ... not usable]
[scanning /u/appel/ml/109/lib/smlnj-lib.cm -> /tmp_mnt/n/fs/fac1/appel/ml/109/src/smlnj-lib/sources.cm]
[checking /tmp_mnt/n/fs/fac1/appel/ml/109/src/smlnj-lib/.alpha32/sources.cm.stable ... ok - stable]
GC #0.0.0.0.1.38:   (11 ms)
[dependency analysis completed]
[compiling toy.lex.sml -> .alpha32/toy.lex.sml.bin]
[wrote .alpha32/toy.lex.sml.bin]
13455
[introducing new bindings into toplevel environment...]
val it = () : unit
- 

hppa% sml 
CM.make();
Standard ML of New Jersey, Version 109, January 19, 1996 [CM&CMB 1]
val it = () : unit
- [starting dependency analysis]
[scanning sources.cm]
[checking .hppa/sources.cm.stable ... not usable]
[scanning /u/appel/ml/109/lib/smlnj-lib.cm -> /tmp_mnt/n/fs/fac1/appel/ml/109/src/smlnj-lib/sources.cm]
[checking /tmp_mnt/n/fs/fac1/appel/ml/109/src/smlnj-lib/.hppa/sources.cm.stable ... ok - stable]
GC #0.0.0.0.1.39:   (20 ms)
[dependency analysis completed]
[compiling toy.lex.sml -> .hppa/toy.lex.sml.bin]
[wrote .hppa/toy.lex.sml.bin]
13573
[introducing new bindings into toplevel environment...]
val it = () : unit
- 

Finally, a transcript on the alpha with only the first two lines of the
sources.cm file:

alpha% sml
Standard ML of New Jersey, Version 109, January 19, 1996 [CM&CMB 1]
val it = () : unit
- CM.make();
[starting dependency analysis]
[scanning sources.cm]
[checking .alpha32/sources.cm.stable ... not usable]
[dependency analysis completed]
[compiling toy.lex.sml -> .alpha32/toy.lex.sml.bin]
GC #0.0.0.0.1.31:   (7 ms)
[wrote .alpha32/toy.lex.sml.bin]
13573
[introducing new bindings into toplevel environment...]
val it = () : unit
- 
Comments:
The last line of the sources.cm file refers to a completely unused
library (with a stable-file).  On the Alpha, this situation leads
to the wrong value for the string literal s5 (I'm quite sure the
problem is in s5 and not in the sum or print functions).
But when the library reference is deleted from the sources.cm file,
it works fine!  Or, on the HP-PA, with or without the library reference,
it works fine!  Most strange.

Owner: ?
Status: open
----------------------------------------------------------------------
Number: 1031
Title: signal handling is broken
Keywords: signal
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			02/05/96
System(s) and Version:	Compiler
SML/NJ Version: 	109.1
Machine: 		SPARC, Solaris 2.4
Severity: 		major
Problem:		signal handling is broken
Code:			OS.Process.system "ls"; OS.Process.system "ls";
Transcript: 		

Script started on Mon Feb 05 15:27:54 1996
sen14_1_109.1/bin/sml
Standard ML of New Jersey, Version 109.1, February 2, 1996 [CM&CMB 1]
val it = () : unit
- OS.Process.system "ls";
108.5		109.1		etc		smlnj
109		bugs		mikpe		typescript
val it = 0 : ?.OS_Process.status

(* OK, fine, let's do it again.. *)

- OS.Process.system "ls";
(* Hangs *HARD* and consumes *LOTS* of CPU *)
^C^C^C^Z
Suspended
sen14_2_kill -9 %1


Script started on Mon Feb 05 15:33:25 1996
sen14_1_109.1/bin/sml
Standard ML of New Jersey, Version 109.1, February 2, 1996 [CM&CMB 1]
val it = () : unit
- case Posix.Process.fork()
= of NONE => (Posix.Process.exit 0w0; 0)
=  | _ => 1;
val it = 1 : int
- val savInt = Signals.setHandler(UnixSignals.sigINT, Signals.IGNORE);
(* As before, hangs consuming lots of CPU *)
^C^C^C^Z
Suspended
sen14_2_kill -9 %1

Comments:		

Using Solaris' `truss' command, I was able to verify that the hanging
process loops entirely in user code. It makes no system calls whatsoever.

The symptoms are similar, but slightly different in 109. There,
it seems to hang right after the first call to OS.Process.system.

NotAFix:			

This doesn't fix the hanging problem, but there is another bug
in sml-nj/boot/Unix/os-process.sml: a typo causing SIGINT to be
given SIGQUIT's handler.

*** sml-nj/boot/Unix/os-process.sml.~1~	Wed Jan 31 17:02:41 1996
--- sml-nj/boot/Unix/os-process.sml	Mon Feb  5 00:54:06 1996
***************
*** 32,38 ****
  		val savSigQuit = savSig UnixSignals.sigQUIT
  		fun restore () = (
  		      Signals.setHandler (UnixSignals.sigINT, savSigInt);
! 		      Signals.setHandler (UnixSignals.sigINT, savSigQuit))
  		fun wait () = (case #2(P_Proc.waitpid(P_Proc.W_CHILD pid, []))
  		       of P_Proc.W_EXITED => success
  			| (P_Proc.W_EXITSTATUS w) => Word8.toInt w
--- 32,38 ----
  		val savSigQuit = savSig UnixSignals.sigQUIT
  		fun restore () = (
  		      Signals.setHandler (UnixSignals.sigINT, savSigInt);
! 		      Signals.setHandler (UnixSignals.sigQUIT, savSigQuit))
  		fun wait () = (case #2(P_Proc.waitpid(P_Proc.W_CHILD pid, []))
  		       of P_Proc.W_EXITED => success
  			| (P_Proc.W_EXITSTATUS w) => Word8.toInt w

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1032
Title: incorrect type paths in signature printing
Keywords: printing, types
Submitter: David MacQueen
Date: 2/9/96
Version: ?
Severity: major
Problem: incorrect type paths in signature printing
Code:
  signature S =
  sig
    structure A : sig type t val y : t end
    val x : A.t
  end;
Transcript: (with Compiler.Control.Print.signatures := 5)
  - use "foo.sml";
  [opening foo.sml]
  signature S =
    sig
      structure A :
	sig
	  type t
	  val y : A.t   (* <--- this should be "t" *)
	end
      val x : A.t
    end

 In 109.19, this is fixed, but type of val x is printed wrong:

  signature S =
    sig
      structure A :
	sig
	  type t
	  val y : t
	end
      val x : ?.t
    end

Test: bug1032.sml
Owner: dbm
Status: fixed in 109.19m [dbm, 11/15/96]
----------------------------------------------------------------------
Number: 1033
Title: assignments to word32 refs are not written to the update log
Keywords: Word32
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 2/13/96 
Version: 109
Severity: extreme
Problem: In SML/NJ 109, assignments to word32 refs are not written to the
update log, which often results in inconsistent heaps (core dumps or
GC detected anomolies).
Code:
	val x = ref (0w0:word32);
	System.Runtime.gc 1;
	x:=0w1;
	System.Runtime.gc 1;
Fix:
To fix this, I modified frun updateOp in translate/unboxed.sml,
generating P.BOXEDUPDATE for word32 assignments.  The new code,
starting at line 50, is:

	  | CONty(tyc,_) =>
	      if       equalTycon(tyc,intTycon)
		orelse equalTycon(tyc,wordTycon)
		orelse equalTycon(tyc,word8Tycon)
	      then P.UNBOXEDUPDATE
	      else if       eqTycon(tyc,realTycon)
		     orelse eqTycon(tyc,word32Tycon)
		     orelse eqTycon(tyc,exnTycon)
		     orelse eqTycon(tyc,contTycon)
		     orelse eqTycon(tyc,arrayTycon)
		     orelse eqTycon(tyc,refTycon)
		   then P.BOXEDUPDATE
		   else P.UPDATE

I don't know why some of the tests use `equalTycon' and other
`eqTycon'.  Please look into this.

[jhr, 2/213/96] Thanks for the bug fix; it will appear in 109.3 (we
just built 109.2 yesterday).  The difference between equalTycon and
eqTycon is that the latter does a "shallow" compare.  I've changed
this to equalTycon in this case.

Test: bug1033.sml
Owner:
Status: fixed in 109.3
----------------------------------------------------------------------
Number: 1034  Word8Vector
Title:vector and String.string types are currently identical
Keywords: 
Submitter: John Reppy
Date: 3/6/96
Version: 109.2
Severity: minor
Problem:  Word8Vector.vector and String.string types are currently identical
Transcript:
  Standard ML of New Jersey, Version 109.2, February 10, 1996 [CM&CMB 1]
  val it = () : unit
  - String.size(Word8Vector.fromList []);
  val it = 0 : int
  -

Test: bug1034.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1035
Title: spurious secondary error message
Keywords: error message, signature matching
Submitter: John Reppy
Date: 3/7/96
Version: 109.2
Severity: minor
Problem: The second error message seems to be caused by the error correction
for the first.
Code: 
  signature S =
  sig
    type t = int
  end;

  structure A: S =
  struct
    type t = bool
  end;

Transcript:
  - use "tests/bug1035.sml";
  [opening tests/bug1035.sml]
  signature S = sig eqtype t end
  tests/bug1035.sml:8.1-11.4 Error: type t does not match definitional specification
  tests/bug1035.sml:8.1-11.4 Error: unmatched type specification: t
Test: bug1035.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/27/97]
----------------------------------------------------------------------
Number: 1036
Title: Word8Array.extract and CharArray.extract are broken
Keywords: Word8Array, CharArray, extract, basis
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			03/10/96
System(s) and Version:	Compiler
SML/NJ Version: 	109.6
Machine: 		all
Severity: 		major (for me)
Problem: 		Word8Array.extract and CharArray.extract are broken
Code:
Transcript:

Standard ML of New Jersey, Version 109.6, March 1, 1996 [CM&CMB 1]
GC #0.0.0.0.1.4:   (20 ms)
val it = () : unit
- val a = CharArray.fromList(explode "abcdefgh");
val a = - : ?.array
- val v = CharArray.extract(a, 0, SOME 4);
GC #0.0.0.1.2.52:   (50 ms)
val v = "abcd\000\000\^A\162" : ?.vector

(* note the garbage bytes after the "abcd" prefix *)

- size v;
val it = 8 : int

(* asked for 4 bytes, got 8 *)

- val a = Word8Array.array(8, 0w65);
val a = - : ?.array
- val v = Word8Array.extract(a, 0, SOME 4);
val v = - : ?.vector
- Word8Vector.length v;
GC #0.0.0.1.3.114:   (20 ms)
val it = 8 : int
- (System.Unsafe.cast v):string;
val it = "AAAA\238\173kh" : string

Comments:

Unrelated, but while I'm writing this bug report, I might as well
mention that the ml-yacc tar file has a junk directory ml-yacc/lib/.depend
and the smlnj-lib tar file has a junk directory smlnj-lib/.rs6000 .

Fix:

The problem is that the size of the result vector is set to be
the size of the input array rather than the number of items
actually extracted. CharVector.extract does this correctly.

*** sml-nj/boot/char-array.sml.~1~	Thu Mar  7 23:19:12 1996
--- sml-nj/boot/char-array.sml	Sun Mar 10 14:28:36 1996
***************
*** 74,80 ****
      fun extract (arr, base, optLen) = let
  	  val len = length arr
  	  fun newVec n = let
! 		val newV = Assembly.A.create_s len
  		fun fill i = if (i < n)
  		      then (vecUpdate(newV, i, unsafeSub(arr, base+i)); fill(i+1))
  		      else ()
--- 74,80 ----
      fun extract (arr, base, optLen) = let
  	  val len = length arr
  	  fun newVec n = let
! 		val newV = Assembly.A.create_s n
  		fun fill i = if (i < n)
  		      then (vecUpdate(newV, i, unsafeSub(arr, base+i)); fill(i+1))
  		      else ()
*** sml-nj/boot/word8-array.sml.~1~	Thu Mar  7 23:19:13 1996
--- sml-nj/boot/word8-array.sml	Sun Mar 10 14:29:55 1996
***************
*** 75,81 ****
      fun extract (v, base, optLen) = let
  	  val len = length v
  	  fun newVec n = let
! 		val newV : vector = V.create len
  		fun fill i = if (i < n)
  		      then (vecUpdate(newV, i, unsafeSub(v, base+i)); fill(i+1))
  		      else ()
--- 75,81 ----
      fun extract (v, base, optLen) = let
  	  val len = length v
  	  fun newVec n = let
! 		val newV : vector = V.create n
  		fun fill i = if (i < n)
  		      then (vecUpdate(newV, i, unsafeSub(v, base+i)); fill(i+1))
  		      else ()

Comment: 
Thanks for the bug report.  I must have broken this when I was changing
these types to be distinct.  I'll fix it for 109.7.

Test: bug1036.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1037
Title: inconsistent type sharing with DEFtycs (Compiler bug)
Keywords: modules, sharing, signatures, instantiation
Submitter: John Reppy
Date: 3/11/96
Version: 109.x
Severity: major
Problem: "Compiler bug: setTycSaccess ERRORtyc" produced by
inconsistent type sharing.
Code:
Transcript:
html-elements.sml:8.9-202.5 Error: Inconsistent type sharing (DEFtyc/DEFtyc) attrs,attrs
Error: Compiler bug: setTycSaccess ERRORtyc
Comments:
This error arises when I use the signature in a functor argument,
The error message should say something about sharing of type abbreviations are
not allowed, and should be generated for the signature definition.

[dbm, 11/1/96] The SML '97 restrictions, when implemented, will rule
out this sort of signature.  Here are two signatures that should not
elaborate, but do without complaint in 109.19:

(* bug1037.sml *)
signature S =
sig
  type s = int
  type t = bool
  sharing type t = s
end;

(* bug1037.1.sml *)
signature S =
sig
  type s = int
  type a t = bool * 'a
  sharing type t = s    (* here the arities don't even agree! *)
end;

Instantiation is no longer being done when a signature is declared.
An error will occur when the sharing constraint is processed during
instantiation, for instance when the signature is used in a functor
parameter spec.  For SML '97, these should be rejected when the signature
is elaborated.

Comment:
  Sharing constraints involving rigid tycons like these are now rejected
  by instantiate.  However, instantiate is not called until the signature
  is used as a functor parameter or the constraint of an opaque match
  (abstraction), so the error will not occur when the signature is defined.  
Test: bug1037.sml, bug1037.1.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 5/20/97]
----------------------------------------------------------------------
Number: 1038
Title: signature instantiation causes uncaught exception Unbound
Keywords: modules, signatures, instantiation
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 3/12/96
Version: 109.6 - 109.21
Severity: major
Problem: signature instantiation causes uncaught exception Unbound
Code: (bug1038.sml)

  signature S =
  sig
    type U
    type a
    datatype 'a internal_address = Address of 'a
    type T = a internal_address
      sharing type T = U
  end;

  functor f(structure s : S) = struct end;

Transcript:
  uncaught exception exception Unbound
    raised at: modules/moduleutil.sml:260.58-260.68
	       util/stats.sml:168.40
	       build/evalloop.sml:145.36
	       build/evalloop.sml:232.54
	       build/evalloop.sml:316.38-316.41

Code: (bug1038.4.sml: another example from Mikael Pettersson, 10/29/96)

  signature SIGA =
  sig
    type t
  end;

  signature SIGB =
  sig
    datatype tt = TT
    type t = tt		(*XXX*)
  end;

  functor F2(structure A : SIGA
	     structure B : SIGB
	     sharing type A.t = B.t) = struct end;	(* fails *)

Comments:
Because of this, the fox net doesn't compile in 109.6.  However, the
polymorphic "'a internal_address" datatype is only there as a
workaround for a bug in the previous module system!  We may be able to
work with 109.6.

Test: bug1038.{1,2,3,4}.sml
Owner: dbm
Status: fixed in 109.22 [109.19m]
----------------------------------------------------------------------
Number: 1039
Title: "Compiler bug: SigMatch.lookTyc 2a" after signature match failure
Keywords: modules, signature matching, secondary error
Submitter: John Reppy, Emden Gansner
Date: 3/13/96
Version: 109.6 - 109.21
Severity: major
Problem: failed signature match causes "Compiler bug: SigMatch.lookTyc 2a"
Code: (* bug1039.sml *)
  structure C =
  struct
    type elem = int
  end;

  signature MV =
  sig
    eqtype  elem
  end;

  signature MA =
  sig
    eqtype  elem
    structure Vector : MV
    sharing type Vector.elem = elem
  end;

  structure s : MA = C;

Transcript:
  - use "tests/bug1039.sml";
  [opening tests/bug1039.sml]
  structure C :
    sig type  elem = int end
  signature MV =
    sig eqtype elem end
  signature MA =
    sig
      eqtype elem
      structure Vector : sig eqtype elem end
      sharing type elem = Vector.elem
    end
  test/tests/hack/g.sml:20.1-20.21 Error: unmatched structure specification: Vector
  Error: Compiler bug: SigMatch:lookTyc 2a

  uncaught exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       modules/sigmatch.sml:376.37
	       modules/sigmatch.sml:694.36
	       modules/sigmatch.sml:758.24
	       elaborate/elabmod.sml:920.8
	       util/stats.sml:168.40
	       test/evalloop.sml:127.37
	       test/evalloop.sml:203.20-203.23

Comment: [dbm,11/25/96] There is an analogous bug for a missing substructure.
This case is represented by bug1039.1.sml.

Test: bug1039.sml, bug1039.1.sml
Owner: dbm
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1040
Title: Match exception after unbound signature name
Keywords: modules, error recovery
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 3/15/96
Version: 109.6--
Severity: minor
Problem: Match exception after unbound signature name
Transcript:
    - functor a(structure b:b) = struct end;
    stdIn:0.0 Error: unbound signature: b
    
    uncaught exception in compiler: Match
      raised at: modules/instantiate.sml:273.7
                 modules/instantiate.sml:564.27
                 modules/instantiate.sml:1003.30
                 util/stats.sml:168.40
                 build/evalloop.sml:127.34
                 build/evalloop.sml:196.62
    - 

Comment [dbm, 11/15/96]]: The secondary error in 109.19m is

    Error: Compiler bug: Instantiate: lookSlot

Test: bug1040.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/29/97]
----------------------------------------------------------------------
Number: 1041
Title: eqtype mismatch despite sharing
Keywords: modules, sharing, signature matching
Submitter: Kenneth Cline <Kenneth_Cline@SILVER.FOX.CS.CMU.EDU>
Date: 3/18/96
Version: 109.6?
Severity: major
Problem:
Here's an example that the new module system won't accept: The problem
that is reported is lack of eqtype in the line declaring result, but
the sharing constraint ensures that X.t is an eqtype.
Code: (* bug1041.sml *)
  signature XTERN =
  sig
    type T
    val t: T
  end

  structure W =
  struct
    type word =  word32
    val zero = 0w0
  end

  functor Ip_Flag_Extern (structure X: XTERN
			  sharing type X.T = W.word) =
  struct
    val result = X.t = W.zero
  end 

Test: bug1041.sml
Owner: dbm
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1042
Title: sig match failure produces "Compiler bug: ElabMod: rebind(TYCspec)"
Keywords: modules, signature matching, error recovery
Submitter: "John H. Reppy" <jhr@research.att.com>
Date: 3/19/96
Version: 109.7
Severity: minor
Problem: sig match failure produces "Compiler bug: ElabMod: rebind(TYCspec)"
Code: (* bug1042.sml *)
  signature SIG =
  sig
    datatype access_mode = A_READ | A_WRITE | A_EXEC
    sharing type access_mode = Posix.FileSys.access_mode
  end;

  structure S : SIG =
  struct
    structure P : sig datatype access = A_EXEC | A_READ | A_WRITE end =
      Posix.FileSys 
    open P
  end;

Transcript:
  - use "tests/bug1042.1.sml";
  [opening tests/bug1042.1.sml]
  GC #0.0.0.1.5.253:   (11 ms)
  signature SIG =
    sig
      datatype access_mode = A_EXEC | A_READ | A_WRITE

      sharing type access_mode = Posix.FileSys.access_mode
    end
  tests/bug1042.1.sml:11.3-12.18 Error: unmatched type specification: access
  Error: Compiler bug: ElabMod: rebind(TYCspec)

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       elaborate/elabmod.sml:802.33
	       elaborate/elabmod.sml:847.33
	       elaborate/elabmod.sml:513.33
	       util/stats.sml:168.40
	       build/evalloop.sml:145.36
	       build/evalloop.sml:232.54
	       build/evalloop.sml:316.38-316.41

Comment [dbm, 11/15/96]: In 109.19m the secondary error has become

  Error: Compiler bug: ModuleUtil: tycId

Test: bug1042.1.sml, bug1042.2.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/29/97]
----------------------------------------------------------------------
Number: 1043
Title: prettyprinting datatypes at top level
Keywords: prettyprinting, top-level
Submitter: Tim Armes <tarmes@armltd.co.uk> (via John Reppy)
Date: 3/21/96
Version: 109.3-109.7
Severity: major
Problem: uncaught exception Match raised while printing a datatype
  decl at top level.
Transcript:
  Standard ML of New Jersey, Version 109.3, February 20, 1996 [new runtime]
  - datatype 'a tree = Node of 'a tree * 'a tree | Leaf of 'a;
  datatype  'a tree
    con Leaf : 'a

  uncaught exception Match
    raised at: print/pptype.sml:190.23
	       util/pp.sml:539.6
	       build/evalloop.sml:176.62

Test: bug1043.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1044
Title: bad type name in top-level printing
Keywords: prettyprinting, top-level, type name
Submitter: Lal George
Date: 3/28/96
Version: 109.3 - 109.19+
Severity: major
Problem: Type names not printed properly at top level. Structure name
  replaced by "?".
Transcript:
  - val x : Word32.word = 0wx400;
  val x = 0wx400 : ?.word
Test: bug1044.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1045
Title: better message for missing spec in signature match
Keywords: printing, error message
Submitter: John Reppy
Date: 2/29/96
Version: 109.19
Severity: minor
Problem: 
  When reporting a missing spec, where the spec is part of a substructure,
  it would be useful if the error message could be localized to the substructure.
  It might also be useful to use a qualified name in the error message.
Code:
  signature S =
  sig
    structure A: sig val x:int end
  end;

  structure X: S =
  struct
    structure A = struct end
  end;

Transcript:
- use "tests/bug1045.sml";
[opening tests/bug1045.sml]
signature S = sig structure A : sig val x : int end end
tests/bug1045.sml:8.1-11.4 Error: unmatched value specification: x

uncaught exception exception Error
  raised at: build/evalloop.sml:123.59-123.67
             build/evalloop.sml:232.54
             build/evalloop.sml:316.38-316.41
-
Test: bug1045.sml
Owner:
Status: open
----------------------------------------------------------------------
Number: 1046
Title: sharing in include not implemented
Keywords: modules, sharing, include
Submitter: Dave MacQueen
Date: 4/1/96
Version: 109.x
Severity: major
Problem: sharing in include not implemented
Code: (* bug1046.sml *)
  signature S =
  sig
    type s
    type t
    sharing type s = t
  end;

  signature T = 
  sig
    include S
    val x : s
    val y : t -> int
  end;

  functor F (X: T) =
  struct
    val _ = X.y(X.x)
  end;

Test: bug1046.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1047
Title: Not very random, random number generator ... (smlnj-lib)
Keywords: random number, smlnj-lib
Submitter: Lal George
Date: 4/3//96
Version: ?
Severity: major
Problem: successive random numbers are identical
Transcript:
  - Rand.random;
  val it = fn : real -> real

  - Rand.random((Rand.randMax + Rand.randMin)/2.0);
  val it = 1073741823.5 : real
  - Rand.random it;
  val it = 1073741823.5 : real
  - Rand.random it;
  val it = 1073741823.5 : real
Comment: [erg, 4/4/96]
In Rand, seeds must be integer-valued. (Rand was implemented
using reals because, at the time, we didn't have large enough
integers.) This constraint should be added to the man
page. Alternatively, Rand could now be reimplemented using
integral types. 

Note that the Random structure provides a much better generator.
Test: bug1047.sml
Owner:
Status: fixed in 110.0.3 (jhr/erg)
----------------------------------------------------------------------
Number: 1048
Title: std_in not reopened after ^D
Keywords: I/O, standard input
Submitter: Bob Harper
Date: 4/10/96
Version: 108.18
System: ?
Severity: major
Problem: 
  There appears to be a bug in 108.18 to do with I/O and the interactive
  system.  It's very easy to reproduce: write a function to read from
  std_in up to eof and make a list out of it.  When you send ^D to
  std_in to finish your input, the top level correctly prints the
  returned list, but then immediately exits because std_in is closed.
  In older versions of SML the behavior was to re-open std_in, which I
  believe is correct.
Code: use bug1048.sml, requires interaction
Test: bug1048.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1049
Title: extraneous unresolved flex record error
Keywords: type checking, flex record, error message
Submitter: 	Thomas Yan (tyan@cs.cornell.edu)
Date: 		4/10/96
System:		Compiler
SML/NJ Version: 0.93 onwards (including 1.09)
Machine: 	all
Severity: 	minor
Problem: 	although there is sufficient information to
		determine all fields of a record, the compiler
		reports an unresolved flex record
Code:		fun f x = (map real (#1 x); map op o x);
Transcript: 	std_in:211.11-211.39 Error: operator and operand don't agree (type mismatch)
		  operator domain: (('Z -> 'Y) * ('X -> 'Z)) list
		  operand:         {1:int list, '...W}
		  in expression:
		    map o x
		std_in:211.1-211.39 Error: unresolved flex record
		(can't tell what fields there are besides #1)
Comment: The problem here is the confusing secondary type error message.
 [dbm, 4/9/97]
  The second error message about "unresolved flex record" appears
  perfectly valid to me.   
Test: bug1049.sml
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number: 1050
Title: uncaught exception Unbound in functor elaboration
Keywords: modules, sharing, instantiation
Submitter:	Roderick Moten    
Date:		April, 12 1996      
Version:        109.10
System:         Sparc/SunOS 4.1.3
Severity:       minor
Problem:        compiler raises the exception Unbound when compiling a
                functor definition.
	
Code: see /usr/local/sml/bugs/moten/1050/src
Transcript:    
- signature i = INFERENCE_ENGINE;
signature i =
  sig
    structure LevelExpression : <sig>
    structure Parameters : <sig>
    structure Terms : <sig>
    structure TermSubst : <sig>
    structure ParmSubst : <sig>
    structure Sequent : <sig>
    structure PrimitiveRule : <sig>
    sharing PrimitiveRule.Sequent = Sequent
    sharing Sequent.TermSubst = TermSubst
    sharing ParmSubst.Terms = TermSubst.Terms = Terms
    sharing Sequent.Parameters = Terms.Parameters = Parameters
    sharing Parameters.LevelExpression = LevelExpression
  end
- functor a (i : INFERENCE_ENGINE) = struct val k = 9 end;

uncaught exception in compiler: Unbound
  raised at: modules/moduleutil.sml:260.58-260.67
             util/stats.sml:168.40
             build/evalloop.sml:133.34
             build/evalloop.sml:202.62 
Owner: dbm
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1051
Title: open decl in signature causes Match exception
Keywords: error message, signature, modules, Match
Submitter: stefan@stefan.hb.north.de (Stefan Westmeier)
Date: 4/15/96
Version: 109.10
System: x86/linux
Severity: major
Problem: Uncaught Match exception when elaborating a signature with
  an open declaration.
Code:
  structure Ab =
  struct
    type AAb = int
    fun I (x:AAb) = x
  end;

  signature BB =
  sig
    open Ab
    val J : AAb -> AAb
  end;

  structure Bb : BB =
  struct
    local open Ab in
      fun J x = I x
    end
  end;

Transcript:
  Standard ML of New Jersey, Version 109.10, April 5, 1996 [CM&CMB 1]
  GC #0.0.0.0.1.1:   (10 ms)
  val it = () : unit
  - use "test.sml";
  [opening test.sml]

  uncaught exception Match
    raised at: elaborate/elabsig.sml:516.5
	       elaborate/elabmod.sml:639.33
	       util/stats.sml:168.40
	       build/evalloop.sml:133.34
	       build/evalloop.sml:202.62
	       build/evalloop.sml:292.22-292.24
  -  
Comments: This is an illegal (SML96) program, but it should produce
  a sensible error message rather than an uncaught Match.

Fix: open is treated as a syntax error
Test: bug1051.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1052
Title: crash on closing an input source
Keywords: I/O, core dump
Submitter:  Roderick Moten <rodmoten@cs.cornell.edu>    
Date:       April 16, 1996
Version:    sml-cm 109.10    
System:         Sun Sparc/Sun OS 4
Severity:       minor
Problem:        sml crashes when attempting to close an input source
Code:           
val ppconsumer = {consumer = Compiler.Control.Print.say, 
		  linewidth = !Compiler.Control.Print.linewidth, 
		  flush = Compiler.Control.Print.flush};

structure Source = Compiler.Source;

val fname = "../../nuprl/envs/top-loop.sml";

val instream = TextIO.openIn fname;

val source = Source.newSource(fname,1,instream,false,ppconsumer,
				SOME TextIO.stdOut);

Source.closeSource source;

Transcript:     
virgo>!!
~sml/src/109.10/bin/sml-cm
Standard ML of New Jersey, Version 109.10, April 5, 1996 [CM&CMB 1]
GC #0.0.0.0.1.5:   (20 ms)
val it = () : unit
- val ppconsumer = {consumer = Compiler.Control.Print.say, 
		  linewidth = !Compiler.Control.Print.linewidth, 
		  flush = Compiler.Control.Print.flush};
= = val ppconsumer = {consumer=fn,flush=fn,linewidth=79}
  : {consumer:string -> unit, flush:unit -> unit, linewidth:int}
- structure Source = Compiler.Source;
structure Source : SOURCE?
- val fname = "../../nuprl/envs/top-loop.sml";
val fname = "../../nuprl/envs/top-loop.sml" : string
- val instream = TextIO.openIn fname;
val instream = ref (ISTRM (-,0)) : ?.instream
- val source = Source.newSource(fname,1,instream,false,ppconsumer,SOME TextIO.stdOut);
val source =
  {anyErrors=ref false,errConsumer={consumer=fn,flush=fn,linewidth=79},
   fileName="../../nuprl/envs/top-loop.sml",
   indexStream=SOME
                 (ref
                    (OSTRM
                       {buf=#,bufferMode=#,closed=#,pos=#,writeArr=#,
                        writeVec=#,writer=#})),interactive=false,lineNum=ref 1,
   linePos=ref [1],sourceStream=ref (ISTRM (-,0))} : ?.inputSource
- Source.closeSource source;
/usr/u/sml/src/109.10/bin/.run/run.sparc-sunos: Error -- Uncaught exception Io with /usr/u/sml/src/109.10/bin/.run/run.sparc-sunos: Error -- <unknown>
virgo>

Comment:
 [jhr, 7/29/1996]
  The problem has to do with the fact that you specify stdOut as the index stream
  (the last argument to newSource).  I think this is causing stdOut to be closed
  when you close the source, which causes an exception to be raised in the
  interactive top-level loop.  I suggest you use NONE as the last argument to
  newSource.

  I think that the Index code is defunct anyway, so we will probably remove this
  from the source.
 [jhr, 4/3/97]
  This was a feature, not a bug, and anyway it is gone now (I removed the
  index stuff).
Test: bug1052.sml
Owner: jhr
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 1053
Title: uncaught exception Bind on opening an unbound structure
Keywords: error message, open
Submitter: George Chesakov <nobby@cnn.Princeton.EDU>
Date: 4/18/96
Version: 109.10
Severity: major
Problem: "open A" where A is not defined produces duplicate error
message and then an uncaught Bind exception.
Transcript:
    Standard ML of New Jersey, Version 109.10, April 5, 1996 [CM&CMB 1]
    GC #0.0.0.0.1.3:   (5 ms)
    val it = () : unit
    - open A;
    stdIn:12.1-12.6 Error: unbound structure: A
    stdIn:12.1-12.6 Error: unbound structure: A

    uncaught exception in compiler: Bind
      raised at: elaborate/elabmod.sml:246.6-255.8
		 elaborate/elabmod.sml:513.33
		 elaborate/elabmod.sml:847.33
		 util/stats.sml:168.40
		 build/evalloop.sml:133.34
		 build/evalloop.sml:202.62

Test: bug1053.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1054
Title: sequential withtype is broken
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			03/24/96
System(s) and Version:	Compiler
SML/NJ Version: 	109.8 (all since at least 109.6)
Machine: 		all
Severity: 		minor
Problem: 		sequential withtype is broken
Code:			

(* bug1054.1.sml *)

functor BugFun() =
struct
  datatype t1 = c1 of t2 * t3
  withtype t2 = t1 list
       and t3 = t2 list	(* this triggers the bug *)
end;

structure Bug = BugFun();

(* bug1054.2.sml *)

datatype t1 = c1 of t2 * t3
withtype t2 = t1 list
     and t3 = t2 list;


(* bug1054.3.sml *)

structure Ok =
struct
  datatype t1 = c1 of t2 * t3
  withtype t2 = t1 list
       and t3 = t2 list
end;

Transcript: 		

Standard ML of New Jersey, Version 109.8, March 25, 1996 [CM&CMB 1]
GC #0.0.0.0.1.5:   (30 ms)
val it = () : unit
- use "bug1054.1.sml";
[opening bug1054.1.sml]
functor BugFun : <sig>

uncaught exception Unbound
  raised at: elaborate/elabmod.sml:513.71-513.80
             util/stats.sml:168.40
             build/evalloop.sml:130.34
             build/evalloop.sml:199.62
             build/evalloop.sml:289.22-289.24
- use "bug1054.2.sml";
[opening bug1054.2.sml]
GC #0.0.0.0.2.39:   (10 ms)
datatype  t1
  
uncaught exception Match
  raised at: print/pptype.sml:190.23
             util/pp.sml:554.6
             build/evalloop.sml:199.62
             build/evalloop.sml:289.22-289.24
- use "bug1054.3.sml";
[opening bug1054.3.sml]
structure Ok :
  sig
    eqtype t3
    eqtype t2
    datatype t1 = c1 of t2 * t3
    
  end
GC #0.0.0.0.3.92:   (20 ms)
val it = () : unit

Test: bug1054.{1,2,3}.sml
Owner: dbm
Status: fixed in 109.19m [dbm, 11/15/96]
----------------------------------------------------------------------
Number: 1055
Title: uncaught Match will printing a datatype decl at top level
Keywords: printing, top-level
Submitter: Mary Fernandez
Date: 3/25/96
Version: 109.6
Severity: major
Problem: uncaught Match will printing a datatype decl at top level
Transcript:
  Standard ML of New Jersey, Version 109.6, March 1, 1996 [CM&CMB 1]
  GC #0.0.0.0.1.2:   (7 ms)
  val it = () : unit
  - datatype X = A of X | B of int;
  datatype  X

  uncaught exception in compiler: Match
    raised at: print/pptype.sml:190.23
	       util/pp.sml:554.6
	       build/evalloop.sml:196.62
Test: bug1055.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1056
Title: uncaught exception kills sml
Submitter:      Roderick Moten <rodmoten@cs.cornell.edu>
Date:           May 27, 1996 
Version:        SML/NJ 109.10
System:         Sparc 20/Solaris 2.5
Severity:       critical
Problem:        SML dies when a compilation error occurs
Code:           
Transcript:  
hercules.cs.cornell.edu>~sml/src/109.10/bin/sml
Standard ML of New Jersey, Version 109.10, April 5, 1996 [new runtime]
- val i  = j;
stdIn:7.10 Error: unbound variable or constructor: j
^C/usr/u/sml/src/109.10/bin/.run/run.sparc-solaris: Error -- Uncaught exception UNDEFINED with /usr/u/sml/src/109.10/bin/.run/run.sparc-solaris: Error -- 0
   
Comments: Accurately speaking, SML dies when an exception is raised and
isn't caught. Entering "raise Match;" at the top level will also cause SML
to die.

[jhr, 5/30/96]
The problem seems to be that SunOS and Solaris are not ABI compatible.  The
short-term fix is to regenerate the sml.sparc heap image on a Solaris
machine.  In the longer term, we will either make heap images OS specific,
or introduce some kind of linking mechanism to dynamically redefine OS
constants.

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1057
Title: typo in error message
Keywords: error message
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			06/19/96
System(s) and Version:	compiler
SML/NJ Version: 	109.14
Machine: 		all
Severity: 		microscopical
Problem: 		typo in error message
Transcript:

- fun foo{x,y,...} = x + size y;
stdIn:12.1-12.29 Error: unresolved flex record (need to know thenames of ALL the fields
 in this context)
  type: {x:int, y:string, '...Z}
                                           missing space here --^

Comments:
Fix:

*** sml-nj/typing/typecheck.sml.~1~	Tue Jun  4 15:52:36 1996
--- sml-nj/typing/typecheck.sml	Wed Jun 19 14:47:02 1996
***************
*** 100,106 ****
  			  WILDCARDty)
  		      | FLEX _ =>
  			 (err loc COMPLAIN 
! 			        "unresolved flex record (need to know the\
  			        \names of ALL the fields\n in this context)"
  			    (fn ppstrm =>
  			       (PPType.resetPPType();
--- 100,106 ----
  			  WILDCARDty)
  		      | FLEX _ =>
  			 (err loc COMPLAIN 
! 			        "unresolved flex record (need to know the \
  			        \names of ALL the fields\n in this context)"
  			    (fn ppstrm =>
  			       (PPType.resetPPType();

Test: bug1057.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1058
Title: misleading error message
Keywords: error message, type printing
Submitter: Anthony Shipman <als@tusc.com.au>
Date: 7/11/96
Version: 109.x
Severity: major
Problem:
  The error below comes from the array arg to FGDyn.sub being of type
  FGInfoDyn.array but the error message suggests that the second argument
  was of the wrong type.

Code:
    type FGNTag = int

    structure FGDyn = DynamicArrayFn(FGMono)
    structure FGInfoDyn = DynamicArrayFn(FGInfoMono)


    type FG = {
	part:	FGDyn.array,
	info:	FGInfoDyn.array
	}

    fun get_node_info(fg: FG, tag: FGNTag) =
	(
	    FGDyn.sub(#info fg, tag)
	)
Transcript:
flow_graph.sml:166.5-168.5 Error: operator and operand don't agree (tycon mismatch)
  operator domain: ?.array * int
  operand:         ?.array * FGNTag
  in expression:
    sub ((fn <pat> => <exp>) fg,tag)
Comments: [dbm, 11/5/96] another case of inaccurate printing of type names
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1059
Title: polyeq broken for vectors
Keywords: polyeq, vectors
Submitter: 		"Daniel C. Wang" <dw3u+@andrew.cmu.edu>
Date: 			4/2/96
System(s) and Version:	Compiler
SML/NJ Version:         109.8 
Machine: 		SunOS, HPUX
Severity: 		major
Problem: 		polymorphic equality is broken for vector values
Code:			- #[1] = #[1,2]
			val it = true : bool
Transcript: 		

Standard ML of New Jersey, Version 109.8, March 25, 1996 [CM&CMB 1]
- #[1,2] = #[1,2];
val it = true : bool

- #[1,2] = #[1];
val it = false : bool

- #[1] = #[1,2];
val it = true : bool
- 
Comments:		Basicly the polyequal code assumes that it's second 
			argument is shorter than the first. 
Fix:			

>From core.sml

  fun polyequal (a : 'a, b : 'a) = peql(a,b)
	    orelse (boxed a andalso boxed b
	    andalso let val aTag = getObjTag a
		        fun pairEq () = 
                          let val bTag = getObjTag b
		           in (ieql(bTag,0x02) orelse ineq(andb(bTag,0x3),0x2))
			      andalso polyequal(sub(a,0), sub(b,0))
			      andalso polyequal(sub(a,1), sub(b,1))
		          end
		     in case aTag
		         of 0x02 (* tag_pair *) => pairEq()
		          | 0x06 (* tag_reald *) => feql(cast a,cast b)
		          | 0x12 (* tag_special *) => false
		          | 0x22 (* tag_record *) => 
                             if ieql(getObjTag b,aTag)
			     then let val lenm1 = (length a)-1
			              fun m (j : int) = if ieql(j,lenm1)
				        then polyequal(sub(a,j),sub(b,j))
				        else polyequal(sub(a,j),sub(b,j)) 
                                             andalso m(j+1)
					(****Change*********)
			           in ieql(length a,length b) andalso m 0
					(****Change*********)
			          end
			     else false
		          | 0x26 (* tag_array *) => false
		          | 0x2a (* tag_string *) => 
                             stringequal(cast a,cast b)
		          | 0x32 (* tag_bytearray *) => false
		          | 0x36 (* tag_realdarray *) => false
		          | _ (* tagless pair *) => pairEq()
		        (* end case *)
		    end)

Test: bug1059.sml
Owner:
Status: fixed in 109.10 [jhr]
----------------------------------------------------------------------
Number: 1060
Title: modmap cleanup expensive
Keywords: modmap, top level
Submitter: Dave MacQueen
Date: 11/5/96
Version: 109.21
Severity: major
Problem: 
SCStatEnv (env/scstatenv.sml) doesn't cleanup the modmaps when
layering its augmented static environments (function atop), which
means that inaccessible structures, signatures, functors etc. 
may not be garbage collected because they still appear in the
modmaps.  This could cause some noticeable space bloat.

The modmaps in the top level static environments are now cleaned up by
applying unSC and then SC to the sc staticEnv.  This is unacceptably
expensive.  Need a new method of cleaning up, or need to do this only
occasionally.

The following code is in the main loop in build/evalloop.sml, and
it appears to be the culprit in a fairly noticeable slowdown in
the interactive system, especially on slow systems (see message
below).

		    val newEnv = SCEnv.Env.concatEnv
		  ({static=newenv,dynamic=new_dynenv,symbolic = new_symenv},
			   #get localEnvRef ())
		  (* refetch localEnvRef because execution may
		   have changed its contents *)

It looks like the reason this is slow is the definition of
SCEnv.Env.concatEnv:

      fun concatEnv(a,b) = SC(E.concatEnv(unSC a, unSC b))

In this case, parameter b is the contents of localEnvRef, which in
sml-cm has a lot of stuff in it, and SC is having to rescan this
environment and rebuild the modmap at each top-level binding.  I
guess this drastic approach is taken to make sure that inaccessible
entities (types, signatures, modules) get cleaned out of the modmap
component of the top-level environment so they can be
garbage-collected.

We need to find a more efficient way of doing this, assuming this
is the correct explanation of the slowdown.

Dave

Date: Mon, 12 Aug 1996 13:57:05 -0500 (CDT)
From: Allen Stoughton <cis.ksu.edu!allen>
To: research.att.com!sml-nj
Subject: Top-level declaration processing overhead in 109.16?

I've noticed that there seems to be a large overhead associated with
processing a top-level declaration in SML/NJ 109.16.

E.g., it makes a big difference whether one types

- val x = 1; val x = 1; val x = 1; val x = 1; val x = 1; val x = 1; val x = 1;

or 

- val x = 1 val x = 1 val x = 1 val x = 1 val x = 1 val x = 1 val x = 1;

On a slow SPARC (SPARCstation 1+) the latter takes about 2 seconds, and
the former takes about 14 seconds (two seconds per top-level declaration).

On a fast (unloaded!) SPARC, of course, one hardly notices the difference...

In contrast, with SML/NJ 0.93, the former takes only slightly more than
1 second, and the later seems to take hardly any time.

Is this a known problem?  I'm worried about teaching with an implementation
in which students must put up with such response times...

Allen

Comment: The main performance problem was an incorrect implementation
of Env.fold that is fixed in 109.22.

Owner: blume, dbm
Status: open
----------------------------------------------------------------------
Number: 1061
Title: RealArray incorrect on x86/Linux
Keywords: RealArray, linux, x86
Submitter: Sven Doerr <sd@ira.uka.de>
Date: 4/24/96
Version: 109.10
System: x86-linux (linux 1.3.74)
Severity: major
Problem: RealArray incorrect on x86/Linux
Transcript:
Standard ML of New Jersey, Version 109.10, April 5, 1996 [new runtime]
- RealArray.array(10,1.0);
val it = - : ?.realarray
- RealArray.sub(it, 8);
val it = 6.15911642003e~312 : real

Fix: The fix is in /home/lorenz/sml/nj/109.X/src/runtime/mach-dep/X86.prim.asm
Test: bug1061.sml
Owner:
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1062
Title: checkCPUTimer raises exception Time
Keywords: checkCPUTTimer, cpu time
Submitter: Roland Olsson <ROLANDO@sofus.hiof.no>
Date: 4/24/96
Version: 109.10
System: x86-linux (200 MHz Pentium Pro, Linux 1.2.13)
Severity: major
Problem: The checkCPUTimer function sometimes gives the following:

uncaught exception Time
boot/time.sml: 78.19-78.22

(checkCPUTimer is being called very soon after creating the timer)
Comments: [jhr, 4/24/96]
We've seen a similar bug under FreeBSD and NetBSD on x86 machines.
The problem is that calls to getrusage may not return monotonically
increasing values for CPU time.  It has something to do with the way
that CPU usage is computed.  You could see if this is the problem
on your machine by adding "defined(OPSYS_LINUX)" to the #ifdef
on line 66 of runtime/kernel/unix-timers.c.  Let me know if this fixes
the problem (or if it doesn't).

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1063
Title: signals not handled when running a saved heap image
Keywords: signals, control-C, exportML
Submitter: Robin Sharp <robin@idatm4.it.dtu.dk>
Date: 5/8/96
Version: 109
System: ?
Severity: major
Problem: 
The handling of signals in SML-NJ 109 seems to be spoiled if a heap image
is saved with exportML, for example in the following way:

Code:
fun xML filename banner =
  let val runtime = List.hd (SMLofNJ.getAllArgs())
      val exec_file = IO.open_out filename

      val _ = IO.output (exec_file,
			 String.concat
			 ["#!/bin/sh\n",
			  runtime, " @SMLdebug=/dev/null @SMLload=", filename,
                          ".heap\n"])
                             (*"@SMLdebug=..." sends GC messages to /dev/null*)

	val _ = IO.close_out exec_file;
	val _ = OS.Process.system ("chmod a+x " ^ filename)
    in exportML (filename^".heap");
       print(banner^"\n")
    end;

xML "Goofy" "New image starts here...";

Comments:
Starting the new image Goofy, one finds that Ctrl/C aborts the program,
rather than just causing an interrupt (with printing of "Interrupt").

After a very large image has been saved (example: the Isabelle system),
the effects of Ctrl/C and Ctrl/D become pretty unpredictable.  In the
Isabelle case, Ctrl/C has no effect, and a looping/long-running
calculation cannot be interrupted.  In another case, Ctrl/D is not
caught and interpreted as EOF (in the end_of_stream function),
but causes immediate program exit.

[jhr, 5/8/96]
I was able to reproduce this bug in 109, but not in 109.11.  Here is the
109.11 code:

fun xML filename banner =
  let val runtime = List.hd (SMLofNJ.getAllArgs())
      val exec_file = TextIO.openOut filename

      val _ = TextIO.output (exec_file,
			 String.concat
			 ["#!/bin/sh\n",
			  runtime, " @SMLdebug=/dev/null @SMLload=", filename,
                          "-image\n"])
                             (*"@SMLdebug=..." sends GC messages to /dev/null*)

      val _ = TextIO.closeOut exec_file;
      val _ = OS.Process.system ("chmod a+x " ^ filename)
    in SMLofNJ.exportML (filename ^ "-image");
       print(banner^"\n")
    end;

Owner:
Status: fixed in 109.11
----------------------------------------------------------------------
Number: 1064
Title: type name printing in signature
Keywords: type printing, signature
Submitter: John Reppy
Date: 5/29/96
Version: 109.10
Severity: major
Problem: proper type path not printed, structure name replaced by ?
Transcript:
  Standard ML of New Jersey, Version 109.10, April 5, 1996 [CM&CMB 1]
  val it = () : unit
  - signature ORD_KEY = sig
  =     type ord_key
  =     val compare : ord_key * ord_key -> order
  =   end;
  signature ORD_KEY =
    sig
      type ord_key
      val compare : ord_key * ord_key -> order
    end
  - signature ORD_LIST = sig
  =     structure Key : ORD_KEY
  =     type 'a ord_list                               
  =     val find : ('a ord_list * Key.ord_key) -> 'a
  =   end;
  signature ORD_LIST =
    sig
      structure Key :
	sig
	  type ord_key
	  val compare : ord_key * ord_key -> order
	end
      type 'a ord_list
      val find : 'a ord_list * ?.ord_key -> 'a
    end
Test: bug1064.sml
Owner: dbm
Status: fixed in 109.19m [dbm, 11/15/96]
----------------------------------------------------------------------
Number: 1065
Title: bug in sockets code
Keywords: sockets
Submitter: Michael Colon <colon@Theory.Stanford.EDU>
Date: 6/1/96
Version: 109
Severity: major
Problem: sockets code incorrect
Fix:

file: boot/Sockets/socket.sml
line: 203
func: chk

reads:               else (buf, i, sz - i)
should read?:	     else (buf, i, sz)

Owner:
Status: fixed in 109.14 (jhr)
----------------------------------------------------------------------
Number: 1066
Title: Fail: uninstantiated VARty in pickmod
Keywords: pickling
Submitter: Andy Koenig
Date: 6/14/96
Version: 109.14, 109.19
Severity: major
Problem: pickling raises Fail: uninstantiated VARty in pickmod
Code: (bug1066.sml)
  fun f() = [];
  let val x = f() in x end;
Transcript: (109.19)
  - use "tests/bug1066.sml";
  [opening tests/bug1066.sml]
  val f = fn : unit -> 'a list
  tests/bug1066.sml:4.5-4.16 Warning: value restriction prevents type variable generalization : 'Z

  uncaught exception Fail: uninstatiated VARty in pickmod
    raised at: pickle/pickmod.sml:483.14-483.51
	       util/stats.sml:168.40
	       util/stats.sml:168.40
	       build/evalloop.sml:145.36
	       build/evalloop.sml:232.54
	       build/evalloop.sml:316.38-316.41
  - 

Here is another instance discovered by Zhong:

  - local val (x, y) = (ref nil, ref nil)
	 in val z = x
	end;
  stdIn:7.7-7.37 Warning: value restriction prevents type variable generalization : 'Z
  stdIn:7.7-7.37 Warning: value restriction prevents type variable generalization : 'Y

  uncaught exception in compiler: Fail: uninstatiated VARty in pickmod
    raised at: pickle/pickmod.sml:467.14-467.50
	       util/stats.sml:168.40
	       util/stats.sml:168.40
	       build/evalloop.sml:142.34
	       build/evalloop.sml:209.62

Fix: 
  Added test in META case in Typecheck.decType:generalizeTy:gen to
  detect when depth was 0, indicating that the type variable had failed
  to be generalized at top level.
Test: bug1066.1.sml, bug1066.2.sml
Owner: dbm, Zhong
Status: fixed in 109.26 [dbm, 3/18/97]
----------------------------------------------------------------------
Number: 1067
Title: mkWriter behavior wrong
Keywords: mkWriter, posix
Submitter: Lorenz Huelsbergen
Date: 6/27/96
Version: 109.?
Severity: major
Problem: 
The mkWriter function in boot/posix-bin-prim-io.sml does not update 
the file position on a write.  This seems to contradict the semantics
of the IO document for writers that implement the *Pos functions;
or am I missing something?

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1068
Title: function printed as "<primop>" rather than "<fn>"
Keywords: printing, top-level
Submitter: Allen Stoughton <allen@cis.ksu.edu>
Date: 6/26/96
Version: 109.?
Severity: minor
Problem: 
Is there a reason why SML/NJ chooses to report some built-in function
values as <primop>'s rather than as fn's?

  - op o;
  val it = <primop> : ('a -> 'b) * ('c -> 'a) -> 'c -> 'b
  - op hd;
  val it = fn : 'a list -> 'a

From the user's point of view, is there really a good reason to
distinguish between these two kinds of things?  I ask partly because I
have to (try to) explain to my students each semester why <primop> has
unexpectedly appeared above...

Test: bug1068.sml

Owner: ?
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 1069
Title: output not flushed when program terminates
Keywords: output, termination
Submitter: Anthony Shipman <tusc.com.au!als>
Date: 7/19/96
Version: 109.15
System: ?
Severity: major
Problem:
Output from TextIO is not flushed at the end of program execution.
I have to remember to do a closeOut or something.  Is this deliberate?
Comments: [jhr, 7/19/96]
This is a bug.  I'll fix it for 109.16.
Owner:
Status: fixed in 109.16?
----------------------------------------------------------------------
Number: 1070
Title: cm fails to write file
Keywords: cm
Submitter:      Roderick Moten rodmoten@cs.cornell.edu
Date:           Mon. July 22, 1996
Version:        sml-full-cm 109.10
System:         Sparc/Solaris 2.5
Severity:       major
Problem:        When attempting to rebuild the compile, cm fails to write assembly.sig.bin after it compiles it.
Comments:
In the transcript, PollEvent = 223686 is printed due to a minor change I made to the runtim system to print the value of PollEvent when a garbage collection check is performed.
                     
Code:  Changes to runtime system can be sent on request. Changes are addition
 to runtime system to support MP for Solaris.      
   
Transcript:  
/../bin/.run/run.mp-sparc-solaris-asm-g @SMLload=/home/sml/src/109.10/bin/.heap/sml-full-cm.sparc
 Standard ML of New Jersey, Version 109.10, April 5, 1996 [CM&CMB 1]
val it = () : unit
- Compiler.Control.CG.pollChecks := true;
val it = () : unit
- SparcVisComp.Control.CG.pollChecks := true;
val it = () : unit
- CMB.make();
[scanning boot/all-files.cm]
PollEvent = 223686  
PollEvent = 223686
PollEvent = 223686
[checking boot/CM/sparc-unix/all-files.cm.stable ... not usable]
[scanning boot/pervasives.cm]
[checking boot/CM/sparc-unix/pervasives.cm.stable ... not usable]
Directory bin.sparc already existed
[Cleaning out binfile directory]
Recompiling boot directory...
[compiling (boot) boot/assembly.sig -> bin.sparc/assembly.sig.bin]
WARNING: no Core access
WARNING: no Core access
WARNING: no Core access
[writing bin.sparc/assembly.sig.bin failed]

uncaught exception Io: openOut failed on file bin.sparc/assembly.sig.bin with SysErr: No such file or directory [<OS.errorName unimplemented>]
  raised at: boot/NewIO/bin-io-fn.sml:620.25-620.71
             compile/cunit.sml:139.13-139.15

Owner: Matthias
Status: not reproducible
----------------------------------------------------------------------
Number: 1071
Title: nonexhaustive match failure while elaborating signature
Keywords: signature, Match, match failure
Submitter: John Reppy
Date: 7/22/96
Version: 109.?
Severity: major
Problem: nonexhaustive match failure while elaborating signature
Code: ~jhr/sml/bmark-suite/programs/boyer
Transcript:
uncaught exception nonexhaustive match failure
  raised at: elaborate/elabsig.sml:516.5
             elaborate/elabmod.sml:639.33
             util/stats.sml:168.40
             build/evalloop.sml:133.34
             build/evalloop.sml:202.62
             build/evalloop.sml:292.22-292.24
Comments: [dbm, 11/5/96] Probably same as bug 1051.  open spec in signature
  at line 8 of boyer.sml.
Fix: open in signature is now a syntax error
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1072
Title: Compiler bug secondary error while elaborating bad functor
Keywords: modules, functor
Submitter: John Reppy
Date: 8/2/1996
Version: 109.19
System: 
Severity: major
Problem: "Compiler bug: setTycSaccess ERRORtyc" elaborating functor
Transcript:
  - functor F (
  =   structure X : sig type t end
  =   structure T : sig type t end
  =     sharing type T.t = Y.t
  =  ) = struct end;
  stdIn:15.18-15.26 Error: unbound structure: Y in path Y.t
  Error: Compiler bug: setTycSaccess ERRORtyc
  - 

In 109.19m the secondary error has become

Error: Compiler bug: ModuleUtil: tycId

Test: bug1072.sml
Owner: dbm
Status: fixed in 109.25.1 [Zhong?]
----------------------------------------------------------------------
Number: 1073
Title: bug in config for 109.16 on hppa
Keywords: configuration, HPPA
Submitter: Anthony Shipman <tusc.com.au!als>
Date: 8/5/1996
Version: 109.16
System: hppa-unix
Severity: major
Problem: inconsistent names for header file
Fix:
Here is a simple patch for the problem.  The runtime and the install.sh had
different ideas about what the suffix should be.

*** machine-id.h-orig	Mon Aug  5 14:59:53 1996
--- machine-id.h	Mon Aug  5 15:07:24 1996
***************
*** 35,40 ****
--- 35,42 ----
  #if   defined(OPSYS_UNIX)
  #  if   (defined(OPSYS_AIX))
  #    define OPSYS_ID	"aix"
+ #  elif (defined(OPSYS_HPUX))
+ #    define OPSYS_ID	"hpux"
  #  elif (defined(OPSYS_FREEBSD) || defined(OPSYS_NETBSD))
  #    define OPSYS_ID	"bsd"
  #  elif (defined(OPSYS_IRIX4) || defined(OPSYS_IRIX5))

Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1074
Title: Infinite loop on divide-by-0 exception
Keywords: divide, floating point, infinite loop, rs6000
Submitter:      Zhong Shao (shao@cs.yale.edu)
Date:           August 8, 1996
Version:        108.21 to 109.15
System:         rs6000-aix
Severity:       minor
Problem:        Infinite loop on divide-by-0 exception
Code:           
                4.0 / 0.0;
Transcript:     

powered% sml
Standard ML of New Jersey, Version 109.15, July 12, 1996 [CM&CMB 1]
val it = () : unit
- 4.0/3.0;
val it = 1.33333333333 : real

- 4.0/0.0;
GC #0.0.0.1.2.50:   (120 ms)
GC #0.0.0.1.3.51:   (140 ms)
GC #0.0.0.2.4.58:   (710 ms)
GC #0.0.1.3.5.59:   (830 ms)
 
Interrupt

Comments:  The bug seems to only occur on the RS6000 platform.
  Exception is raised correctly on sparc-solaris. 

Comments: [Neil Inala, 8/13/1996]
The following code segments all give the same perpetual GC problem
with the divide-by-zero exception.  It seems to have something to
do with refs.  I don't think the particular value of any of the
reals gives a problem (except of course 0.0).

These both compile and f(1.0) executes fine, but
trying to get the value of v gives perpetual GC:

  val v = ref 4.0;
  fun f(x) = v := x / 0.0;

or:

  val v = ref 4.0;
  fun f(x) = v := x / real(0);


This compiles and f(1.0) and g(1.0) execute fine, but
trying to get the value of v gives perpetual GC:

  val v = ref 4.0;
  fun f(x) = (v := x / 0.0; v)
  fun g(x) = (v := x / 0.0; !v)

This compiles and f(1.0) executes fine, but
trying to get the value of v or w gives perpetual GC:
  val v = ref 4.0;
  val w = ref 5.0;
  fun f(x) = w := (v := x / 0.0; !v)

Comment: [jhr, 8/13/1996]
I wonder if trapping divide by zero is disabled and the looping
is the printer trying to print a NaN?  I guess that moving to
non-trapping arithmetic should fix this problem.

Comment: [lal, 8/96]
The bug has to do with the fact that the floating point traps are not 
correctly enabled.

Test: bug1074.sml
Owner: John
Status: obsolete [new basis]
----------------------------------------------------------------------
Number: 1075
Title: Infinite loop during profiling
Keywords: profile, infinite loop
Submitter:      Zhong Shao (shao@cs.yale.edu)
Date:           August 8, 1996
Version:        109.15
System:         rs6000-aix 
Severity:       minor
Problem:        Infinite loop during profiling
Code:           
                Compiler.Profile.setMode(Compiler.Profile.LATENT);
                fun f x = 3;
                Compiler.Profile.reset();
                f 3;
                Compiler.Profile.report(TextIO.stdOut);

Transcript:     (* The above code infinite loops *)

powered% sml
Standard ML of New Jersey, Version 109.15, July 12, 1996 [CM&CMB 1]
GC #0.0.0.0.1.1:   (10 ms)
val it = () : unit
- Compiler.Profile.setMode(Compiler.Profile.LATENT);
                fun f x = 3;
                Compiler.Profile.reset();
                f 3;
                Compiler.Profile.report(TextIO.stdOut);
Creating profiled version of standard library
GC #0.0.0.1.2.48:   (40 ms)
val it = () : unit
- val f = fn : 'a -> int
- val it = () : unit
- GC #0.0.0.1.3.111:   (20 ms)
val it = 3 : int
-  %time cumsec #call  name
 

Comments:       There are no GC messages, so the infinite loop does not
                allocate. The profiling works ok on sparc-solaris.
Test: bug1075.sml
Owner: John
Status: fixed in 109.32 [jhr, 9/22/97]
----------------------------------------------------------------------
Number: 1076
Title: CM+exportFn creates too large images
Keywords: cm, image size
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			08/12/96
System(s) and Version:	probably CM and/or runtime
SML/NJ Version: 	109.16
Machine: 		sparc-solaris; maybe others?
Severity: 		major
Problem: 		CM+exportFn creates too large images
Code:
Transcript:
Comments:

I'm observing large variations in the sizes of images (from exportFn)
when using CM. Specifically, when doing a clean build (all CM sub-directories
removed, newly started sml-cm process) so that CM recompiles everything,
the images are from 29% to 70% larger than normal. If I then restart
sml-cm and CM.make() again, the exported images are back to normal sizes.
I suspect some form of space leak, perhaps in CM (but shoudln't CM.clear()
empty all in-core caches?).

Here is a list of some of my SML applications, and the image sizes
after a 1st (clean) build, and then after a 2nd (trivial) build.

application	1st build	2nd build	1st/2nd increase

rml2c:		2008828		1181332		70%
rmli:		1130652		799940		41%
rmli-V2:	1270468		873288		45%
emil:		849620		659064		29%
xdrgen:		585316		396336		48%

Comment: [blume, 8/12/96]
You said you are using exportFn.  Do your projects themselves make any
references to CM?  If this is not the case (the size of the images
seem to support this), then CM has nothing to do with it, because all
of it should get stripped out by exportFn.

[Mikael Pettersson, 3/13/97]
08/12/96 I reported a problem I've been having with 109.16 and some
earlier versions: exportFn created overly large images for "1st builds"
using CM. Since then, whatever caused this seems to have been fixed,
because now (with 109.25 and 109.25.2) the "1st build" produces images
of normal sizes. However, for some reason the "2nd build" (which is a
CM.make() that doesn't have to recompile anything) now results in slightly
(a few %) _larger_ images. (Nothing else has changed. Same machine,
same OS, same SML code.)

So perhaps #1076 can be taken off the openbugs list now?

Owner: Matthias
Status: fixed in 109.26 [Matthias]
----------------------------------------------------------------------
Number: 1077
Title: lack of info in CM error message
Keywords: CM, error message
Submitter: Anthony Shipman <tusc.com.au!als>
Date: 8/13/1996
Version: 109.16
Severity: minor
Problem:
The following error is not very useful.  It would be an improvement
if the names in the cycle were listed.

!* CM error: ../semantics/utils.sml: cycle among definitions involving structure
SemUtils 

Owner: Matthias
Status: fixed in 109.22
----------------------------------------------------------------------
Number: 1078
Title: exception Unbound generated when applying a functor
Keywords: modules, functor, Unbound exception
Submitter: Stephen Weeks <research.nj.nec.com!sweeks+>
Date: 8/14/1996
Version: 109.15
Severity: major
Problem: exception Unbound generated when applying a functor
Transcript:
  Standard ML of New Jersey, Version 109.15, July 12, 1996 [CM&CMB 1]
  val it = () : unit
  - functor Bug() =
  struct
     datatype foo = Foo
     withtype bar = int
     and baz = bar list
  end;
  functor Bug : <sig>
  - structure Bug = Bug();

  uncaught exception in compiler: exception Unbound
    raised at: elaborate/elabmod.sml:513.71-513.80
	       util/stats.sml:168.40
	       build/evalloop.sml:133.34
	       build/evalloop.sml:202.62

Test: bug1078.sml
Owner: dbm
Status: fixed in 109.19m [dbm, 11/15/96]
----------------------------------------------------------------------
Number: 1079
Title: constructor types omitted when printing structure signature
Keywords: printing, top level, signature, datatype
Submitter: Norman Ramsey
Date: 8/15/96
Version: 109.16
Severity: major
Transcript:
- structure foo = struct datatype 'a group = GROUP of 'a list | SINGLE of 'a end;
structure foo :
  sig
    datatype 'a group = GROUP | SINGLE
    
  end

Test: bug1079.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/29/97]
----------------------------------------------------------------------
Number: 1080
Title: "Compiler bug: SigMatch.lookStr 2a" during signature match
Keywords: signature match, compiler bug
Submitter: Norman Ramsey 
Date: 8/19/96
Version: 109.16?
Severity: major
Transcript:
[compiling link.sml (via: link.sml@link.nw) -> CM/x86-unix/link.sml.bin]
link.nw:22.23-22.46 Error: unmatched structure specification: Denotable
link.nw:22.23-22.46 Error: unmatched type specification: group
link.nw:22.23-22.46 Error: unmatched constructor specification: GROUP
link.nw:22.23-22.46 Error: unmatched constructor specification: SINGLE
link.nw:22.23-22.46 Error: unmatched value specification: insistSingle
link.nw:22.23-22.46 Error: unmatched value specification: elab
Error: Compiler bug: SigMatch.lookStr 2a

uncaught exception exception Error
  raised at: util/errormsg.sml:51.14-51.19
             modules/sigmatch.sml:285.27
             modules/sigmatch.sml:612.24
             modules/sigmatch.sml:651.26
             elaborate/elabmod.sml:513.33
             util/stats.sml:168.40
             sched/recompile.sml:196.38-196.41

Owner: dbm
Status: unreproducible (possibly obsolete)
----------------------------------------------------------------------
Number: 1081
Title: difficult type error message
Keywords: error message, type checker
Submitter: Norman Ramsey
Date: 8/22/96
Version: 109.16
Severity: major
Problem: 
Code:
Transcript:
solve.nw:40.9-59.4 Error: value type in structure doesn't match signature spec
    name: solve
  spec:   {eqns:?.equation list, inputs:?.set}
          -> {answers:?.intexp ?.map, constraints:?.boolexp_set,
              unsolved:?.equation list}
  actual: {eqns:?.equation list, inputs:?.set}
          -> {answers:?.intexp ?.map, constraints:?.boolexp_set,
              unsolve:?.equation list}

!* CM error: compile: elaboration failed
- 

Comments:
Obviously it's time for a rousing game of find the sharing constraint.
The compiler could make the game easier to win by attaching unique ids
to the ? marks, so that I know right away which of the five pairs of ?'s
don't match.
[later...]
It turned out there was no missing sharing constraint --- I had
misspelled the name of a record element ("unsolve").  That, too, would
have been easier to find had I *known* all the ?'s matched...

Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1082
Title: inconsistent opsys string for freebsd
Keywords: configuration
Submitter: Robert Findler <cs.rice.edu!robby>
Date: 8/13/96
Version: 109.?
System: x86-freebsd
Severity: minor
Problem: 
When I compile on freebsd, some parts of the system use "freebsd" as
the arch string (e.g., .arch-n-opsys) and some parts (the binaries??) use
"bsd" as the arch string.
Owner: John
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1083
Title: truncation of printing of concrete values
Keywords: printing, datatypes, top level
Submitter: Allen Stoughton <cis.ksu.edu!allen>
Date: 8/23/96
Version: 109.16
Severity: major
Transcript:
  Compiler.Control.Print.printDepth := 25;
  datatype foo = A | B of foo;
  - B A;
  val it = B - : foo

another example from Carlos Puchol:

  - datatype 'a T = E | B of int * 'a T;
  datatype  'a T
    con B : int * 'a <RECtyc 0>    (* note RECtyc! *)
    con E : T
  - val p = B (0, B (2, B (4, E)));
  val p = B (0,-) : 'a T
  -

Test: bug1083.sml
Owner: dbm
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1084
Title: hole in value restriction implementation (bottom type)
Keywords: type checking, value restriction
Submitter: Zhong Shao, Allen Stoughton <cis.ksu.edu!allen> 
Date: 8/28/96
Version: 109.16
Severity: major
Problem: 
Because of the special case in the value restriction for expressions
with a simple type variable in their type, certain expressions that
should not be typed are accepted.

Transcript:
  - hd nil;

  uncaught exception exception Empty
    raised at: boot/list.sml:42.38-42.42
  - fun f x = f x;
  val f = fn : 'a -> 'b
  - f 0;
  (... infinite loop ...)
  Interrupt

Comments:
This exception to the value restriction was introduced to support
bootstrapping, so that declarations like the following would work

  val x : 'a array = System.Unsafe.cast Array.array0Fix:

Fix: find an alternate way of supporting such bootstrapping definitions
Test: bug1084.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1085
Title: rebinding a data constructor name allowed using val rec
Keywords: binding, data constructor
Submitter: Sandip Biswas <saul.cis.upenn.edu!sbiswas>
Date: 9/9/96
Version: 0.93
Severity: major
Problem: 
As per the definition a data constructor can be redefined only
as yet another data constructor of different type.
But SML/NJ does not seem to check this when we use the val rec
declaration.

Code:
Transcript:
- datatype AA = A | B ;
datatype  AA
  con A : AA
  con B : AA
- val B = fn x => 90 ;
std_in:11.1-11.18 Error: pattern and expression in val dec don't agree
(tycon mismatch)
  pattern:    AA
  expression: 'Z -> int
  in declaration:
    B = (fn x => 90)

Things are working here right as they are supposed to.  But the
following should not work.

- val rec B = fn x => 90 ;
val B = fn : 'a -> int

Test: bug1085.1.sml, bug1085.2.sml
Owner: dbm
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1086
Title: illegal signature decl inside structure not rejected
Keywords: modules, error message, signature, structure
Submitter: Christian Fecht
Date: 9/11/96
Version: 109.17, 109.19
Severity: major
Code:
structure A =
struct
  type variable = int
  signature S =
    sig
      type t
      val f    : t * variable -> t
    end
  structure B : S =
  struct
    type t = variable list
    fun f(s,_) = s
  end
end
Transcript:
- use "tests/bug1086.sml";
[opening tests/bug1086.sml]

uncaught exception exception Unbound
  raised at: elaborate/elabmod.sml:513.71-513.81
             util/stats.sml:168.40
             build/evalloop.sml:145.36
             build/evalloop.sml:232.54
             build/evalloop.sml:316.38-316.41
- 
Comments:
Signature declarations are not allowed inside structures.  This
should be detected and a proper error message produced.

In 109.19m through 109.25.2, this is accepted without an error message.

Test: bug1086.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1087
Title: "Compiler bug: PPObj: switch: none of the datacons matched"
Keywords: printing, datatype, top level
Submitter: Carlos Puchol (cpg@research.bell-labs.com)
Date: 9/19/96
Version: 109.17
Severity: major
Problem: printing a value of a datatype causes
  Compiler bug: PPObj: switch: none of the datacons matched"
Code:
  datatype d = D of t
  and s = A of int | B of int
  and t = C of s;

  val p = C(B 0);
Fix: typo in print/ppobj.sml (i for index)
Test: bug1087.sml
Owner: dbm
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1088
Title: overly large integers make sml hang
Keywords: overflow, integer literals
Submitter: mjd@plover.com (Mark-Jason Dominus)
Date: 9/30/96
Version: 0.93
System: x86-linux (Linux 1.2.8)
Severity: major
Code:
32768*32768;
1103515245;
Test: bug1088.1.sml, bug1088.2.sml
Owner: 
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1089
Title: bogus data constructor representations
Keywords: printing, data constructor, representations, datatype
Submitter: Dave MacQueen
Date: 10/3/96
Version: 109.18
System: SGI/IRIX 5.2
Severity: critical
Problem: bogus data constructor representations
Code: 

(* 1. causes memory fault *)

datatype d = D of t
and s = A | B of string
and t = C of s;

val p = C(B "a");


(* 2. Change order of type definitions ==> no problem *)

datatype s = A | B of string
and t = C of s
and d = D of t;

val p = C(B "b");


(* 3. Change argument of B to int ==> when printing p get
   Compiler bug: PPObj: switch: none of the datacons matched *)

datatype d = D of t
and s = A | B of int
and t = C of s;

val p = C(B 0);


(* 4. Or add an argument for A ==>
   Compiler bug: PPObj: switch: none of the datacons matched *)

datatype d = D of t
and s = A of int | B of string
and t = C of s;

val p = C(B "a");


(* 5. Now change argument of B to int ==>
      Compiler bug: PPObj: switch: none of the datacons matched *)

datatype d = D of t
and s = A of int | B of int
and t = C of s;

val p = C(B 0);


(* 6. Eliminate datatype d ==> no problem, prints p ok *)

datatype s = A of int | B of int
and t = C of s;

val p = C(B 0);
 
Owner: dbm
Status: fixed in 109.19
----------------------------------------------------------------------
Number: 1090
Title: rs6000-aix chokes on real literals
Keywords: real literals, rs6000
Submitter: Robert Findler <cs.rice.edu!robby>
Date: 10/5/96
Version: 109.19
System: rs6000-aix ( RS6000 N40 laptop running aix 3.2)
Severity: major
Transcript:
Standard ML of New Jersey, Version 109.19, October 5, 1996 [CM; autoload enabled]
GC #0.0.0.0.1.1:   (30 ms)
- 1.1;
GC #0.0.0.1.2.37:   (110 ms)

uncaught exception in compiler: overflow
  raised at: util/pp.sml:554.6
             build/evalloop.sml:232.54
Comments:
That expression works fine on solaris, sunos and freebsd.

Comments: [Lal, 10/5/96]
Hmm. On an older RS6000 running AIX 3.2, this seems to work fine

  zion$ bin/sml
  Standard ML of New Jersey, Version 109.19, October 5, 1996 [CM&CMB 1]
  GC #0.0.0.0.1.5:   (50 ms)
  val it = () : unit
  - 1.1;
  val it = 1.1 : real

Comments: [Findler]
Just in case, I did reboot and it's not the problem. I did narrow it down a
little more:

- Real.toString 1.1;

uncaught exception overflow

- Real64.toString 1.1;

uncaught exception overflow

and

- fun f x = f x;
GC #0.0.0.1.4.158:   (30 ms)
val f = fn : 'a -> 'b
- f 1.1;

runs for a while just fine.

So, I looked at real-format.sml in the boot directory and saw that it was
calling realGFormat (1.1,12) and that the exception was being raised in
decompose when it is called with (12,0,fn _=>12). So, htat is calling a
local function mkdigits with argument (1.1,12), which overflows.

Well, to make a long story short, (well, just to end up my long story, I
guess :-)

- floor 1.1;

uncaught exception overflow

That's as far as I can go, since:

real64.sml:    val floor = Assembly.A.floor

and I wouldn't have the foggiest if I looked at that code.

Test: bug1090.sml
Owner: Lal
Status: fixed in 109.25 [Lal]
----------------------------------------------------------------------
Number: 1091
Title: word conversion causes "Compiler bug: 3312 in CPSgen"
Keywords: word, conversion
Submitter: Chris Paris <cap@cmu.edu>
Date: 10/7/96
Version: 109.18
System: ?
Severity: major 
Transcript:
% sml
Standard ML of New Jersey, Version 109.18, September 16, 1996
- Word.toInt (Word.fromInt 0);
 copy_31_192((I)0) -> 193[I]
 {193} -> 194
 201(201,202,203,204,194)

Error: Compiler bug: 3312 in CPSgen
- 

Comments:
The SML system dies with an illegal instruction if you try to do
anything beyond that point. Below is a fix.

Fix:
*** sml-nj/cps/contract.sml.orig	Mon Sep 16 09:10:28 1996
--- sml-nj/cps/contract.sml	Fri Oct  4 17:28:28 1996
***************
*** 827,833 ****
  	   if m >= p then checkClicked("C5", n2, m, PURE, P.copy)
  	   else checkClicked("C6", n2, m, ARITH, P.test)
  	 | P.testu(n2,m) => 
! 	   if m >= p then checkClicked("C7", n2, x, PURE, P.copy)
  	   else checkClicked("C8", n2, m, ARITH, P.testu)
  	 | _ => skip()
       end
--- 827,833 ----
  	   if m >= p then checkClicked("C5", n2, m, PURE, P.copy)
  	   else checkClicked("C6", n2, m, ARITH, P.test)
  	 | P.testu(n2,m) => 
! 	   if m >= p then checkClicked("C7", n2, m, PURE, P.copy)
  	   else checkClicked("C8", n2, m, ARITH, P.testu)
  	 | _ => skip()
       end

Test: bug1091.sml
Owner: Lal
Status: fixed in 109.25 [Lal]
----------------------------------------------------------------------
Number: 1092
Title: subscript out of bounds while printing data structure
Keywords: printing
Submitter: Carlos Puchol (cpg@cs.utexas.edu)
Date: 10/7/96
Version: 109.19
System: ?
Severity: major 
Problem: 
Top level prettyprinting of large structure fails with subscript out
of bounds exception.
Code:
  datatype m = M of ifc option
  and ifc = IFC;

  val x = SOME IFC;  (* must be SOME *) (* x prints ok *)
  val y = M x; (* printing y fails with subscript out of bounds *)
Transcript:
uncaught exception in compiler: subscript out of bounds
  raised at: boot/list.sml:50.35-50.44
             util/pp.sml:554.6
             build/evalloop.sml:232.54

[dbm] Here is another related anomaly:
Code:
  datatype 'a s1 = S1 of 'a
  and s2 = S2;

  datatype m = M of n s1
  and n = N;

  M(S1 N);
Transcript:
  - use "bug1092.1.sml";
  [opening g.sml]
  datatype 'a s1 = S1 of 'a
  datatype s2 = S2
  datatype m = M of n s1
  datatype n = N
  val it = M (S1 S2) : m   (* not right! - should be "M (S1 N)" *)
  val it = () : unit
  - 
Test: bug1092.sml, bug1092.1.sml, bug1092.2.sml
Owner: dbm
Status: fixed in 109.23 [dbm]
----------------------------------------------------------------------
Number: 1093
Title: abstype causes "Compiler bug: tycEntVar DEFtyc u"
Keywords: abstype
Submitter: Lars Birkedal <cs.cmu.edu!birkedal>
Date: 10/8/96
Version: 109.16
Severity: major
Transcript:
  structure S = struct
    abstype t = A with type u = t end
  end;

  - structure S = struct
  =    abstype t = A with type u = t end
  =  end;
  []
  Error: Compiler bug: tycEntVar DEFtyc u
  - 
Comment: [dbm, 11/5/96]
  In 109.19 (mipseb-unix) caused core dump, but then generated above
  error message in a fresh sml.
Test: bug1093.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1094
Title: CM_ROOT environment variable not seen by cm
Keywords: cm
Submitter: Anthony Shipman <tusc.com.au!als>
Date: 10/9/96
Version: 109.18
Severity: major
Problem: 
  If I do

      $ CM_ROOT=some.cm sml
      - CM.make();

  then it ignores the CM_ROOT and uses sources.sml.  If I set the root
  manually it works.

      $ sml
      - CM.set_root "some.cm";
      - CM.make();
Fix:
The bug is on config/install.sh.

CM uses its own ``export'' routine (in place of SMLofNJ.exportML),
which makes sure that environment variables are re-read when the
system comes back up.  The install script doesn't use CM's ``export''
function, so changes in environment variables are not honored anymore.

Please, replace the line that says

	SMLofNJ.exportML "sml-cm";

with

	CM.export ("sml-cm", NONE);

in config/install.sh.

Comments: [jhr, 10/9/96]
Wouldn't it be better to just call OS.Process.getEnv when you need the value
of CM_PATH.  Also, there is a mechanism in the compiler for doing this kind
of initialization (sml-nj/boot/cleanup-sig.sml, sml-nj/boot/cleanup.sml).
The advantage of using the builtin mechanism is that when some unsuspecting
user does an exportML, it will behave correctly.

Comments: [Anthony Shipman, 10/11/96]
That works. But I now get two banners.

Standard ML of New Jersey, Version 109.18, September 16, 1996 [CM&CMB 1]
Standard ML of New Jersey, Version 109.18, September 16, 1996 [CM; autoload ena

Owner: blume
Status: fixed in 109.21 [jhr]
----------------------------------------------------------------------
Number: 1095
Title: inadaquate type error message
Keywords: error message, type checking
Submitter: Anthony Shipman <tusc.com.au!als>
Date: 10/13/96
Version: 109.18
System: x86-linux
Severity: major
Problem: 
I have some type checking code that has the following relevant lines.

fun check_val_decls(...) =
let
    ......
    val init_result = ...  (* something of known type UnifyResult *)
    val final_result = do_val_decls(struct_tag, inherits, init_result)
    val final_subst = finish_subst(#subst final_result)
    ....
in ... end
....

and get_let_type(...) =
let
    ...
    val decl_rslt = do_val_decls(let_tag, inherits, rslt_in)
    ...
in ... end

and do_val_decls(
	let_tag: Tag,
	inherits: Inherits, 
	rslt_in: UnifyResult
	): UnifyResult =
let ... end


I got the following error message where line 1296 is the second use of
do_val_decls()

../semantics/type_check.sml:1296.2-1296.58 Error: unresolved flex record
(can't tell what fields there are besides #subst)


It appears that because the first encounter of do_val_decls() was in
check_val_decls() it decided that the result type of do_val_decls() was
unknown but at least was a record with a field 'subst'.

When it got to line 1296 it decided to report its confusion.  A solution
was to add a constraint

    val decl_rslt: UnifyResult = do_val_decls(let_tag, inherits, rslt_in)

I think the type error reporting needs some more smarts.

Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1096
Title: abstype name not printed properly
Keywords: printing, type name
Submitter: George Luger
Date: 10/13/96
Version: 109.21
Severity: major
Problem:
At top level, a datatype name is printed properly, but if the datatype
is changed to an abstype, a "?." is added to the name.
Code:
Transcript:
Standard ML of New Jersey, Version 109.21, October 28, 1996 [CM; autoload enabled]
- datatype 'a q = Q of 'a list;
datatype 'a q = Q of 'a list
- val empty = Q [];
val empty = Q [] : 'a q
- abstype 'a q = Q of 'a list
= with
= val empty = Q []
= end;
type 'a q
val empty = - : 'a ?.q
- 
Comment: [dbm]
  The problem is that the type of empty *in the absyn* contains a local
  stamp for q that has been replaced by a pid in the static environment
  that is used for printing.  Thus the version of q in the absyn for
  the empty declaration is not equal (equalTycon) to q in the static
  environment that is passed to the prettyprinting function.
Fix: fetch the types for the body values from the static environment
Test: bug1096.sml
Owner: dbm
Status: fixed in 109.19m
----------------------------------------------------------------------
Number: 1097
Title: implimentation of floor_a primitive on Alpha
Keywords: Alpha, floor
Submitter: Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu> 
Date: 10/14/96
Version: 19.18?
System: alpha32-unix
Severity: major
Problem: 
  There is a cvttqvm instruction in floor_a (ALPHA32.prim.asm) that is
  not implemented by the alpha processors (at least not the ones we
  have).  Worse, yet, we have an alpha/OSF1 system here that refuses to
  emulate this instruction, resulting in an illegal instruction signal.

Fix:
  Here's my fix to floor_a.  It appears to work, but I haven't tested it
  thoroughly.

  ML_CODE_HDR(floor_a)
	  ldt	$f0,0(STDARG)		/* get argument */
	  fblt	$f0, 2f			/* jump if argument is negative */
	  cvttqvc	$f0,$f0			/* round to quadword */
	  cvtqlv	$f0,$f0			/* convert quad to long */
	  sts	$f0,-4($30)		/* store temporarily into C stack */
	  ldl	ATMP1,-4($30)		/* load from C stack */
	  addlv	ATMP1,ATMP1,ATMP2	/* make room for tag bit */
  1:	bis	ATMP2,1,STDARG		/* add the tag bit */
	  CONTINUE
  2:	/* negative argument */
	  /* cvttqm (x) = cvttq (2*x - 0.5) / 2 */
	  /* cvttq (x-0.5) loses for odd integers which IEEE round to evens */
	  lda	$0,0xC1E0000000000000	/* t-floating -2147483648.0 ... */
	  stq	$0,8($sp)		/*  ... (minimum 31 bit signed int) */
	  ldt	$f1, 8($sp)		/* load min into $f1 */
	  subt	$f0, $f1, $f1		/* is arg too small? */
	  fblt	$f1, 3f			/* jump if yes (underflow) */
	  lda	$0,0x3FE0000000000000 	/* t-floating -0.5 */
	  stq	$0,8($sp)		/* move via stack ... */
	  ldt	$f1, 8($sp)
	  addt	$f0, $f0, $f0		/* compute ... */
	  subt	$f0, $f1, $f0		/*  ... 2*x + 0.5 */
	  cvttq	$f0, $f0		/* round to int */
	  stt	$f0, -8($30)		/* move via stack ...
	  ldq	STDARG, -8($30)
	  sra	STDARG, 1		/* halve */
	  br	1b
  3:	eqv	STDARG, STDARG, STDARG /* generate overflow */
	  sll	STDARG, 63, STDARG
	  addqv	STDARG, STDARG, STDARG
	  trapb
	  CONTINUE

Owner: Lal
Status: fixed in 109.25.1
----------------------------------------------------------------------
Number: 1098
Title: Compiler bug: type conflicts happened in transtypes unWRAPOp
Keywords: representation
Submitter:              Ed Osinski - osinski@cs.nyu.edu
Date:                   Oct. 15, 1996
System(s) and Version:  sml-cm
SML/NJ Version:         109.15, 109.19, 109.21
System:                 sun4, SunOS 4.1.4
Severity:               minor
Problem:                Compiler bug - type conflicts

Code: (bug1098.sml)
  structure T : sig end =
  struct
    datatype B = U

    fun FVu'  depth (_,  acc) = acc
    and FVus' depth (xs, acc) = foldl (FVu' depth) acc xs

    fun FVb depth U = FVu' depth ((), [])

    fun wrap_FV FV' (d : int) = FV' d

    fun FVus d = wrap_FV FVus' d
  end

Transcript:    

Standard ML of New Jersey, Version 109.19, October 5, 1996 [CM; autoload enabled]
- use "bug1098.sml";
[opening bug1098.sml]
**** warning: type conflicts ***** 
*** T1 is *** 
I 
*** T2 is *** 
P 
**** the source types are ***** 
*** TT1 is *** 
(I->({I,R}->R)) 
*** TT2 is *** 
(P->({I,R}->R)) 
Error: Compiler bug: type conflicts happened in transtypes unWRAPOp
The lvar 129448 is not in the current hashtable!
Error: Compiler bug: TypeInfo hash table in convert.sml

uncaught exception exception Error
  raised at: util/errormsg.sml:51.14-51.19
             cps/convert.sml:751.3
             cps/convert.sml:751.3
             util/stats.sml:168.40
             util/stats.sml:168.40
             build/evalloop.sml:232.54
             build/evalloop.sml:316.38-316.41
- 

Comments:               

The code above is the smallest that would exhibit the bug.  For example,
any of the following changes will make the bug disappear:

* Removal of the empty signature constraint
* Removal of function FVb
* Removal of function FVus
* Changing the "and" to "fun", making the definitions of FVu' and FVus'
  non-recursive
* Removal of the int constraint on d in the definition of wrap_FV

Test: bug1098.sml
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1099
Title: real equality broken
Keywords: real, equality
Submitter: Takashina Tomomi (tomo@sw.cas.uec.ac.jp)
Date: 10/14/96
Version: 109.19
System: ?
Severity: major
Problem: 
Code:
  fun uniq0(nil, _) = nil
    | uniq0(a1::nil, pv) = if a1<>pv then a1::nil else nil
    | uniq0(a1::a2::al, pv) = if a1=pv then uniq0(a2::al, pv)
				 else if a1=a2 then a1::uniq0(al, a2)
					       else a1::uniq0(a2::al, a1)
  and
      uniq(nil) = nil
    | uniq(a1::nil) = a1::nil
    | uniq(a1::a2::al) = if a1=a2 then a1::uniq0(al, a2)
				  else a1::uniq0(a2::al, a1);

  uniq [3.0,3.0,4.0,4.0,5.0,9.0,9.0,9.0];
Transcript:
Standard ML of New Jersey, Version 109.19, October 5, 1996 [CM; autoload enabled]
- use "tests/bug1099.sml";
[opening tests/bug1099.sml]
val uniq0 = fn : ''a list * ''a -> ''a list
val uniq = fn : ''a list -> ''a list
GC #0.0.0.1.2.43:   (32 ms)
val it = [3.0,3.0,4.0,4.0,5.0,9.0,9.0,9.0] : real list
val it = () : unit
- 

Test: bug1099.sml
Owner: Lal
Status: fixed in 109.21
----------------------------------------------------------------------
Number: 1100
Title: Compiler bug secondary error elaborating bad functor (SML96)
Keywords: modules, functor, signature, sharing, type abbreviations, error recovery
Submitter: 		Mikael Pettersson (mpe@ida.liu.se)
Date: 			10/17/96
System(s) and Version:	compiler
SML/NJ Version: 	109.19
Machine: 		all
Severity: 		?
Problem: 		type sharing may be broken
Code:

signature SET =
sig
  structure Key : sig type key end
  type item = Key.key
end;

signature FOO =
sig
  structure StringSet : SET
  sharing type string = StringSet.item
end;

functor FooFun(structure StringSet : SET
	       sharing type string = StringSet.item	(*XXX*)
		 ) : FOO =
struct
  structure StringSet = StringSet
end;

Transcript:

bug.sml:12.9-17.6 Error: Inconsistent type sharing (PRIMITIVE/?) string, item
Error: Compiler bug: SigMatch.lookTyc 1a

uncaught exception exception Error
  raised at: util/errormsg.sml:51.14-51.19
             modules/sigmatch.sml:298.27
             modules/sigmatch.sml:307.27
             modules/sigmatch.sml:612.24
             modules/sigmatch.sml:651.26
             util/stats.sml:168.40
             build/evalloop.sml:145.36
             build/evalloop.sml:232.54
             build/evalloop.sml:316.38-316.41

Comments:

This involves an SML'96 feature (type abbreviations in signatures),
so it may be that the compiler actually does what SML'96 requires.
Until the new Definition is generally available, I cannot really
determine what the correct behaviour is supposed to be...

If I change the sharing constraint (*XXX*) to read: .. = StringSet.Key.key
instead, then things work fine. But why accept the FOO signature at the
top-level while rejecting an identical copy used as a functor argument?

In the excerpt of the new Definition (version 7.3.4) distributed with MLWorks,
it says that every longtycon involved in a type sharing constraint must
denote a flexible type name. However, I found no mention of whether a
type abbreviation of the kind found in the SET signature denotes a flexible
or rigid type name.

This example is condensed from a real application where I used the
smlnj-lib ORD_SET signature and BinarySetFn functor to build different
set-of-FOO structures.

Comment [dbm]: In 109.19m, the secondary error has become

  Error: Compiler bug: TypesUtil: tycStamp ERRORtyc

Test: bug1100.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 5/21/97]
----------------------------------------------------------------------
Number: 1101
Title: puzzling type error message
Keywords: error message, type checking
Submitter: Dave MacQueen
Date: 10/28/96
Version: 109.19
Severity: minor
Problem: 
Shouldn't the last line of the transcript below be

  f : int -> 'Y

Transcript:
- fun k x y = x;
val k = fn : 'a -> 'b -> 'a
- val f = k 3;
stdIn:17.1-17.12 Error: nongeneralizable type variable
  f : 'Z -> 'Y
- 
Comment: The last line should be "f : 'Z -> int".  It is now.
Test: bug1101.sml
Owner: dbm
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 1102
Title: bogus type sharing not rejected
Keywords: modules, signatures, sharing
Submitter: Dave MacQueen
Date: 10/29/96
Version: 109.19
Severity: major
Problem: 
The following signature is accepted even though the type sharing
equates types with different equality properties.
Code:
  signature S =
  sig
    eqtype s
    datatype t = C of int -> int
    sharing type s = t
  end;
Comments:
This declaration is accepted, but if we then use the signature
as a parameter signature in a functor declaration like

functor F(X: S) = struct end;

we get the error message

  tests/bug1102.sml:10.9-10.31 Error: inconsistent equality properties

  uncaught exception exception Error
    raised at: build/evalloop.sml:123.59-123.67
	       build/evalloop.sml:232.54
	       build/evalloop.sml:316.38-316.41

This is because instantiation is not performed on signatures when they
are declared, and instantiation is where inconsistent sharing is
detected.

Test: bug1102.sml
Owner: dbm
Status: not a bug (in SML 96)
----------------------------------------------------------------------
Number: 1103
Title: OS_IO signature is not bound at top level
Keywords: OS_IO, top level
Submitter: Lorenz Huelsbergen
Date: 11/1/96
Version: 109.21
Severity: minor
Problem: 
The signature name OS_IO is not bound in the top level environment.
This leads to the question mark being printed after it in the
following transcript.

Transcript:
  Standard ML of New Jersey, Version 109.21, October 28, 1996 [CM; autoload enabled]
  - open OS;
  open OS
  structure FileSys : OS_FILE_SYS
  structure Path : OS_PATH
  structure Process : OS_PROCESS

  structure IO : OS_IO?
		      ^
		      |------------ ???

Fix: bind OS_IO in the top level
Owner: jhr
Status: fixed in 109.26 [jhr, Lal, 3/19/97]
----------------------------------------------------------------------
Number: 1104
Title: CM path mechanism broken
Keywords: CM, CM_PATH
Submitter: Tomas Uribe <Theory.Stanford.EDU!uribe>
Date: 11/1/96
Version: 109.21
Severity: major
Problem: 
There seems to be a problem with CM's path mechanism; the CM_PATH is
not working properly.

In particular, CM seems to be looking for everything relative to the
directory where the .cm file is located. A simple example:

Running sml-cm from directory X, which is the same as CM_PATH:
	sources.cm is Alias foo/main.cm;
where X/foo/main.cm has a reference to "test.sml", which resides in X/test.sml.
Then CM will look for test.sml in the directory X/foo, not in the
directory X, even though the CM_PATH is X.

Also, the type of the CM.set_path function is not the one in the CM
manual, instead of
	string list -> unit
it is now
	string list option -> string list

Comment: [dbm] Is this the same as bug 1094?

Comment: [blume, 11/27/96]
  Indeed, this might be the same problem as 1094, but I doubt it.
  Instead, the logger seems to have misunderstood the PATH mechanism:
  CM only uses the path if the file can not be found in its
  default location.  The person writing the error report seems to
  assume that with CM_PATH set CM will _only_ look into the path.
  In other words, if sources.cm lists a.sml, and there is a file
  a.sml in the same directory that contains sources.cm, then this
  a.sml will be used -- regardless whether or not there is a CM_PATH,
  and regardless of whether or not the path contains another a.sml.

Owner: blume
Status: not a bug
----------------------------------------------------------------------
Number: 1105
Title: message for uncaught exceptions has duplicated "exception"
Keywords: message
Submitter: Dave MacQueen
Date: 11/7/96
Version: 109.21
Severity: minor
Transcript:
- exception Foo;
exception Foo
- raise Foo;

uncaught exception exception Foo
  raised at: stdIn:18.7-18.10
- 
Comments:
  Also, should eliminate the extra newline.
Test: bug1105.sml
Owner: Lal
Status: fixed in 109.26 [Lal, jhr, 3/19/97]
----------------------------------------------------------------------
Number: 1106
Title: cutoff recompilation broken
Keywords: CM, cutoff recompilation
Submitter: Dave MacQueen
Date: 11/12/96
Version: 109.21
Severity: major
Problem: adding some print statements to a file (build/boot.sml),
caused unnecessary cascading recompilation of files like cps/shareglue.sml.
Transcript: 
- CMB.make();
[starting dependency analysis]
[parsing build/boot.sml]
GC #2.10.11.13.82.1702:   (44 ms)
[dependency analysis completed]
Compiling...
GC #3.11.12.14.83.1847:   (1094 ms)
[compiling build/boot.sml -> bin.mipseb-unix/boot.sml.bin]
GC #3.11.12.14.84.1884:   (37 ms)
build/boot.sml:220.3-332.6 Warning: binding not exhaustive
          (nil,env) = ...
build/boot.sml:220.3-332.6 Warning: binding not exhaustive
          STRbind (STRvar {binding=binding,daccess=daccess,name=name,
                           saccess=saccess}) = ...
GC #3.11.12.14.85.1911:   (24 ms)
GC #3.11.12.14.86.1918:   (34 ms)
GC #3.11.12.14.87.1927:   (16 ms)
GC #3.11.12.14.88.1943:   (23 ms)
[wrote bin.mipseb-unix/boot.sml.bin]
[recovering bin.mipseb-unix/shareglue.sml.bin... failed]
[compiling cps/shareglue.sml -> bin.mipseb-unix/shareglue.sml.bin]
GC #3.11.12.14.89.1972:   (14 ms)
[wrote bin.mipseb-unix/shareglue.sml.bin]
...
Comment: 
 [Matthias, 11/25/96]
  (This one is not owned by anyone, but it seems like it is at
  least CM-related.)
  I noticed the same problem.  My guess is that under certain
  circumstances a change in the implementation can introduce subtle
  changes to the resulting static environment.  (Ordering
  problems, optional redundant information (e.g. lambda-types)
  present or absent, ...).  A while back I traced a similar (but
  much more pronounced) effect to optional lambda-type
  annotations.  I fixed this bug by calculating the CRC without
  taking those lambda-types into account.  This is a rather nasty
  hack... I'd rather see such optional information disappear from
  static environments altogether.

 [Matthias, 2/19/97]
  I have the sneaking suspicion that bugs 1106, 1135, and 1154 are
  really all the same bug or at least very closely related.

 [Matthias, 3/31/97]
  I haven't seen a case of 1106 recently.  Has anyone else experienced
  spurious recompilations after adding print statements to other modules
  etc.?

 [Matthias, 4/16/97]
  Here is a small example that exhibits the problem.  If I remove the
  comments around "local", "in", and "end" below, then CM thinks it
  needs to recompile b.sml.  I believe this should never happen, because
  whether the definition of x is local or not isn't exposed in the
  functor's interface (which is given by the signature constraint).
  BTW, I get the same behavior for transparent and opaque signature
  matching.

  Likewise, adding any definition to the functor body thot is not
  mentioned in the signature will also cause b.sml to be recompiled.

  -Matthias

  The code is here:

  sources.cm::
  ---------------------------
  Group is
	  a.sml
	  b.sml
  ---------------------------

  a.sml::
  ---------------------------
  signature AS = sig

      val a: int -> int

  end

  functor AF ():> AS = struct
  (*    local *)
	  val x = 1
  (*    in *)
	  fun a n = n + x
  (*    end *)
  end
  ----------------------------

  b.sml::
  ----------------------------
  structure B = struct

      structure A = AF ()

      val b = A.a 10

  end
  ----------------------------

 [Blume, 4/21/97: cutoff compilation still broken]
  The following example breaks cutoff recompilation.  Un-commenting the
  type definition within functor AF causes b.sml to be recompiled:

  sources.cm::
  ----------------------------
  Group is a.sml b.sml
  ----------------------------

  a.sml::
  ----------------------------
  signature AS = sig

      val a: int -> int

  end

  functor AF ():> AS = struct

      (* type ttt = unit *)

      fun a (x: int) = x

  end
  ----------------------------

  b.sml::
  ----------------------------
  structure B = struct

      structure A = AF ()

      val b = A.a 10

  end
  ----------------------------
 [Zhong, 4/21/97]
  This really depends on whether ttt is used (or referred) by function
  a or not [rather, appears in a's interface type-dbm]. The current compiler
  considers all types can potentially be used, so it can definitely be optimized.

 [Matthias Blume, 4/21/97]
  I don't understand this.  Whether ttt is used in a or not shouldn't
  matter.  I can see that there might be problems if it becomes part of
  a's type.  But even then, suppose a depends on tttt, but a certain
  change to tttt does not change the type of a.  In this case cutoff
  compilation should also work (imo).

  Example:

  functor ...: sig val a: unit -> int end = struct

  type foo = unit   (* changes to foo do not change the type of a *)
  type ttt = int * foo

  fun a () = let val x: ttt = (3, ()) in #1 x end

  end

 [Zhong, 4/21/97]
  You are right. Unfortunately, the current static representations of the
  functor body is too coarse-grain to identify these differences. We'll
  see how to improve on this in the future.

 [Matthias, 4/30/97]
  Bug 1106 has been fixed, although I am personally not quite satisfied
  with the current status.  The example that I submitted is now
  processed correctly. But adding, deleting, or changing any type
  declarations in a functor's body (even when they are masked away by a
  signature contraint) will cause changes in the static environment,
  therefore in the pickle, and will therefore cause unnecessary
  recompilation.

  Zhong said that that's an artifact of the current implementation
  strategy.

 [dbm, 5/1/97]
  We'll have to work on this, and I hope we can eliminate any
  sensitivity to internal types.  Is the current effect caused by
  changes in the lambda types, Zhong?

 [Zhong, 5/1/97]
  No, it has nothing todo with lambda types. The functor body entity
  declaration currently faithfully record every type declaration it
  encounters --- so if any internal type declaration changes, the
  functor body entity expressions will change, thus the functor signature.

  If we want to get fancy, we can minimize the body entity expressions
  by throwing away all the unreachable type declarations, but this can
  be tricky to implement though.

Owner: Andrew, dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1107
Title: Io exception in compiler
Keywords: Io, <stdIn> Interrupted system call.
Submitter: nikolaj@cs.stanford.edu
Date: 11.11.96
Version: 109.21.1
System: Solaris
Severity: 
Problem: 
 The compiler raises the following exception:

 uncaught exception in compiler: Io: input failed on "<stdIn>",    
Interrupted system call
  raised at: boot/NewIO/text-io-fn.sml:132.14-132.56
             elaborate/frontend.sml:119.24
             util/stats.sml:168.40
             build/evalloop.sml:232.54

 It is repeated until selecting CTRL-C

Code: bug1107.sml
  I am not sure where this happens, but functions that
  are used include: OS.FileSys.openDir, closeCir, readDir, isDir, isLink
  
Comments:
  The bug is hard to reproduce which points to os specific problems.
  We have a file browser that reads directories and sorts files from 
  directories, then lists them in separate boxes.

  Note also that OS.FileSys.isDir raises a SysErr exception when the
  path is not a directory (instead of returning false). Try for instance:

   OS.FileSys.isDir "/c/is/my/favorite/language/because/I/love/to/add/pointers/";

  assuming you do not have such strange directories.

 [jhr]
  I think this was because they were mixing CML and SML/NJ's I/O.
Test: bug1107.sml
Owner: John
Status: not a bug
----------------------------------------------------------------------
Number: 1108
Title: String.maxSize missnamed as String.maxLen
Keywords: basis
Submitter: Lorenz Huelsbergen
Date: 11/8/96
Version: 109.21.1
Severity: minor
Fix: change the name
Owner: John
Status: fixed in 109.26 [Lal, jhr, 3/29/97]
----------------------------------------------------------------------
Number: 1109
Title: boxity exception
Keywords: datatypes, representation, printing
Submitter: Chris Paris <cmu.edu!cap>
Date: 11/19/96
Version: 109.21.1
System: sparc/solaris (SunOS 5.5), mipseb/irix
Severity: major
Problem: values of a datatype cause Boxity exception or core dump.
Transcript:
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996
  - datatype 'a lyst = NIL | CONS of ('a * 'a lyst) ref;
  datatype 'a lyst = CONS of ('a * 'a lyst) ref | NIL
  - val a = CONS (ref ("foo", NIL));

  uncaught exception in compiler: exception Boxity
    raised at: boot/system.sml:133.34-133.40
	       util/pp.sml:554.6
	       build/evalloop.sml:232.54

and again --

  Standard ML of New Jersey, Version 109.21.1, November 4, 1996
  - datatype 'a lyst = NIL of string | CONS of ('a * 'a lyst) ref;
  datatype 'a lyst = CONS of ('a * 'a lyst) ref | NIL of string
  - val a = CONS (ref ("foo", NIL "nil"));

  Process sml bus error

Test: bug1109.1.sml, bug1109.2.sml
Owner: dbm
Status: fixed in 109.23 [109.19m]
----------------------------------------------------------------------
Number: 1110
Title: problem printing datatype
Keywords: datatypes, printing
Submitter: Chris Paris <cmu.edu!cap
Date: 11/19/96
Version: 109.21.1
System: sparc/solaris (SunOS 5.5), mipseb/irix
Severity: major
Problem: datatype value prints incorrectly
Transcript:
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996
  - datatype lyst = NIL of string | CONS of (string * lyst) ref;
  datatype lyst = CONS of (string * lyst) ref | NIL of string
  - val a = CONS (ref ("foo", NIL "nil"));
  val a = CONS (ref ("foo",ref -)) : lyst
  - Compiler.Control.Print.printDepth := 100;
  val it = () : unit
  - Compiler.Control.Print.printLength := 100;
  val it = () : unit
  - val a = CONS (ref ("foo", NIL "nil"));
  val a = CONS (ref ("foo",ref -)) : lyst
  - (* Why does the second ref print as -? More problems in the printer? *)
Test: bug1110.sml
Owner: dbm
Status: fixed in 109.23
----------------------------------------------------------------------
Number: 1111
Title: failure to generalize type variable
Keywords: type checking, polymorphism, value restriction
Submitter: John Reppy
Date: 12/4/96
Version: 109.21.1, 109.19m, 
Severity: major
Problem: a type variable that should generalize does not.
Transcript:
  - let val [f] = [] in f 1; f true end;
  stdIn:8.1-8.36 Error: nongeneralizable type variable
    it : 'Z

Comment: the type of the let expression is a type variable, which
  can't be generalized because the expression is not a value.
Test: bug1111.sml
Owner: dbm
Status: not a bug
----------------------------------------------------------------------
Number: 1112
Title: missing region info in match nonexhaustive message
Keywords: error messages
Submitter: Zhong Shao (shao-zhong@cs.yale.edu)
Date: 1/3/97
Version: 109.22
Severity: minor
Problem: region is not defined for a "match nonexhaustive"
  warning message for a top-level function definition.  Also
  null if the definition appears in either part of a top-level
  local declaration.
Transcript:
(1)
  - fun f [] = 1;
  stdIn:<nullRegion> Warning: match nonexhaustive
	    nil => ...

  val f = fn : 'a list -> int
(2)
  - local fun f [] = 1 in val x = 3 end;
  stdIn:<nullRegion> Warning: match nonexhaustive
	    nil => ...

  val x = 3 : int
  - local val x = 3 in fun f [] = x end;
  stdIn:<nullRegion> Warning: match nonexhaustive
	    nil => ...

  val f = fn : 'a list -> int

Comments:
  It seems to be defined (modulo accuracy of line numbers) for
  local definitions in a top-level let expression or in a top
  level function declaration.
Test: bug1112.1.sml, bug1112.2.sml, bug1112.3.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1113
Title: inappropriate error message for missing @SMLload arg
Keywords: error message, heap image
Submitter: John Reppy (Kent Lee <leekent@luther.edu>)
Date: 1/7/96
Version: 109.22
Severity: major
Problem: User used the wrong syntax for the @SMLload command line option
and got an inappropriate error message.
Transcript:
  sml @SMLload "genesis" filename
  /usr/local/sml109.22/bin/.run/run.mipseb-irix5: Fatal error -- incorrect
  byte order in heap image

Comments:
The image file genesis was created by exportFn.  The command line should
have been

  sml @SMLload=genesis filename

This error should have been detected and a more appropriate error
message should be given.
Owner: jhr
Status: fixed in 109.28 [jhr]
----------------------------------------------------------------------
Number: 1114
Title: installing prettyprinter for type created by a functor
Submitter:      Elsa L. Gunter
Date:           7 January 1997
Version:        109.22
System:         linux, version 2.0
Severity:       major
Problem:        When a type is first defined in a functor, and then you
                apply the functor to get a structure, and then install a
                pretty-printer for the type, the installed pretty-printer
                is ignored.
Code:
(* File: pp_bug.sml *)

functor TYPE () =
struct
datatype ty = Tyc of string
end;

structure Type = TYPE();

(*
structure Type = 
struct
datatype ty = Tyc of string
end;
*)

structure P =
struct

fun pp_type ppstrm (Type.Tyc tyname) = 
   (Compiler.PrettyPrint.begin_block ppstrm Compiler.PrettyPrint.CONSISTENT 0;
    Compiler.PrettyPrint.add_string ppstrm tyname;
    Compiler.PrettyPrint.end_block ppstrm)

end;

val _ = Compiler.PPTable.install_pp ["Type","ty"] P.pp_type;

val test_type = Type.Tyc "bool";

Transcript:

sml
Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled]
- use "pp_bug.sml";
use "pp_bug.sml";
[opening pp_bug.sml]
functor TYPE : <sig>
structure Type :
  sig
    datatype ty ... (hidden constructors)
  end
structure P : sig val pp_type : ?.ppstream -> ?.ty -> unit end
val test_type = Tyc "bool" : ?.ty
val it = () : unit
- 

Comments:
The problem goes away (ie. the installed pretty-printer is used) if you
just define the type in a structure from the begining.

Fix:
Test: bug1114.1.sml, bug1114.2.sml
Owner: dbm
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1115
Title: vector pattern matching bug
Keywords: vectors, pattern matching
Submitter: Greg Morrisett (jgm@cs.cornell.edu)
Date: Jan. 30, 1996
Version: 109.24
System: Win-NT
Severity: severe
Problem: Compiling the following file causes a Compiler bug: LambdaType: wrong
TC_TUPLE in tc_select.
Code:
  fun f #[1] = 0 | f _ = 1;
Transcript:
  - use "test.sml";
  [opening test.sml]
  Error: Compiler bug: LambdaType: wrong TC_TUPLE in tc_select
Fix: change to translate/matchcomp.sml in 109.25
Test: bug1115.sml
Owner: Zhong Shao
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1116
Title: performance problems in top level loop
Keywords: performance, top-level
Submitter: Larry Paulson
Date: 11/26/96
Version: 109.21
System: ?
Severity: major
Problem: 
  I'm afraid I'm having serious problems with performance in version 109.21.  My 
  overnight Isabelle runs, which take under three hours under Poly/ML and just 
  over 3 1/2 hours with 108.5, are taking upwards of 10 hours (yes, 10) with 
  109.21.  I also noticed this interactively yesterday, when a Poly/ML job 
  started later on a slower computer finished before the same job under 109.21.  
  These runs consist almost entirely of execution, not compilation.

  I find this rather discouraging, especially in that I have gone to a lot of 
  trouble to port Isabelle to a recent version.  What do you think could be 
  wrong?

  ======= followup, 11/26/96
  Here are some elapsed time for building some of the various modules.  (All
  times are cumulative, measured from the start of the job.)

		  109.21		Poly/ML 3.1
  Pure:		5 minutes	3 minutes	[mostly compilation]
  FOL+ZF:		3:31 hours	22 minutes	[mostly proofs]
  HOL:		9:28 hours	1:18 hours	[mostly proofs]

  HOL would have suffered from being in competition with Poly/ML.  (The SML/NJ
  job starts at 22:00, while the Poly/ML one starts at 04:00.  Normally 6 hours
  is much more than enough.)

  The true slowdown is much worse than a factor of three, as you can see.
  Compatibility problems (such as calls to makestring) made the 109.21 job crash
  shortly after building HOL. 

  One particular example (ZF/ex/CoUnit) takes 70 seconds (including 1.6 seconds
  for GC) with 109.21, against 5.2 seconds with Poly/ML.

  The machine is a Sun SuperSPARC with 200+ meg.
Comments:
  Almost certainly due to top-level loop overhead, probably associated
  with maintenance of modmap in SCStaticEnv, i.e. running SC to often
  on too large a static environment.  Zhong is working on a fix:

    Dave, this is consistent with what I have found. The sml-cm compiler
    has the "CM" and "CMB" module in its top-level interactive environment.
    Both CM and CMB are huge structures. Everytime, we do a top-level
    compilation (thus doing the SCEnv.concatEnv), the old environment is 
    being un-SCed and then SCed again; and simplying SC-ing the "CM" and 
    "CMB" structures would take huge amount of time (around 0.7 sec on Sparc20).

    In 109.23m (the version I sent to you), I introduced some lazy-concat on 
    modmaps. This helps relieve the problem a bit, but not completely. I 
    a better fix though: the top-level env will always be SCStatenv, the
    result of elaborate should always be bare statEnv, the "concatEnv" operating
    should SC the new bare statEnv in the old modmap --- this will avoid 
    rebuilding the old modmap over and over again. After we do this, we can
    do reference counting on modmap to eliminate the potentional space-leak
    problem (similar to what Matthias did in stalePid).

Fix: streamline modmap management
  env/scstatenv.sml
  build/evalloop.sml
  build/compile.sml
   Fix the BUG 1116 about very slow top-level interactive loop, reported 
   by Larry Paulson (Dave, if you have HOL with you, can you test this out?)
Test: isabelle, HOL
Owner: Dave, Zhong, Matthias
Status: (check) fixed in 109.25.1 
----------------------------------------------------------------------
Number: 1117
Title: SIGINT handling
Keywords: signals, SIGINT
Submitter: Tore Jahn Bastiansen <toreba@ifi.uio.no>
Date: 11/27/96
Version: 109.21.1
System: sparc/solaris
Severity: major 
Problem: 
  There seems to be a problem with signal handeling in sml/nj 109.21.1
  After recovering from Control-C, SML does not shut down properly. 
  The signals is also passed on to the parent process.
Transcript:
  This script, 'status', prints exit status, and, if the 1st argument is 
  'trap', it traps SIGINT.
  ----------------------------------
  #!/bin/sh

  if [ "trap" = $1 ] 
  then 
    trap "echo Trapped SIGINT" 2
     shift
  fi

  CMD=$1
  shift
  $CMD $*

  echo Exist status: $?
  ----------------------------------

  I have tested it on the toplevel loop on sparc-solaris

  ~ #45>status sml-cm
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload 
  enabled]
  - OS.Process.exit 1;
  Exist status: 1


  ~ #46>status sml-cm
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload 
  enabled]
  - ^C
  Interrupt
  -  OS.Process.exit 1;
  [No output from status]

  ~ #47>status trap sml-cm
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload 
  enabled]
  -  OS.Process.exit 1;
  Exist status: 1


  ~ #48>status trap sml-cm
  Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload 
  enabled]
  - ^CTrapped SIGINT                   <-------------

  Interrupt
  -  OS.Process.exit 1;
  Exist status: 130

  On mipseb-irix, Control-C makes an infinite loop printing 

  uncaught exception in compiler: Io: input failed on "<stdIn>", I/O error
    raised at: boot/NewIO/text-io-fn.sml:132.14-132.56
	       elaborate/frontend.sml:119.24
	       util/stats.sml:168.40
	       build/evalloop.sml:232.54



  The following program has similar problems:

  exception SigInt

  fun test() =
    let
      val oldHandler = Signals.inqHandler Signals.sigINT
      fun loop() = loop()
    in
      let
	val intcont = 
	  SMLofNJ.callcc(fn k => (SMLofNJ.callcc(fn k' =>(SMLofNJ.throw k k'));
				  raise SigInt))
	val newHandler = Signals.HANDLER(fn _ => intcont)
      in
	Signals.setHandler(Signals.sigINT,newHandler);
	loop()
      end
      handle SigInt => (Signals.setHandler(Signals.sigINT,oldHandler);
			print "Hello World!\n")
    end

Comments: 
 [jhr, 11/27/96]
  This is strange, and I'll look into it.  BTW, the fact that your shell script
  also receives the signal is just because it is in the same process group
  as SML.  SIGINT is delivered to all of the processes in the group associated with
  the tty.
 [jhr, 3/7/97]
  I think that what is happening is that the ^C kills the shell script, but the
  SML process is still running.  This is why there is no status message in the
  second example.  The infinite loop on SGI with ^C is not reproducable.  The
  example program provided seems to work fine.
Fix:
Test:
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1118
Title: Compiler bug: 222 in prof
Keywords: profiler
Submitter: John Reppy
Date: 11/21/96
Version: 109.21.1
System: ?
Severity: major 
Problem: 
  Trying to compile the compiler with profiling enabled results in the
  following compiler bug.
Transcript:

  Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM&CMB 1]
  val it = () : unit
  - Compiler.Profile.setMode Compiler.Profile.LATENT;
  Creating profiled version of standard library
  val it = () : unit
  - CMB.make();
  [scanning boot/all-files.cm]
  [checking boot/CM/mipseb-unix/all-files.cm.stable ... not usable]
  [scanning boot/pervasives.cm]
  [checking boot/CM/mipseb-unix/pervasives.cm.stable ... not usable]
  [Cleaning out binfile directory]
  Recompiling boot directory...
  [compiling (boot) boot/assembly.sig -> bin.mipseb-unix/assembly.sig.bin]
  Error: Compiler bug: 222 in prof

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
  - 
Comments:
Fix:
Test:
Owner: Andrew
Status: open
----------------------------------------------------------------------
Number: 1119
Title: excessive memory usage
Keywords: memory, performance
Submitter: Tore Jahn Bastiansen <toreba@ifi.uio.no>
Date: 12/12/96
Version: 109.22
System: Sparc Ultra 1/Solaris
Severity: major
Problem: 
  My problem is that some data neves seems to be freed
  (Or maybe it's just not returned to the operatins system).
  After allocating 10,000,000 integers several times, always overwriting
  the last one (using val it = Array.array(10000000,1);), I cannot
  get memory useage below 200Mb, even if I say.
  val it= <some low cost expr>;

  If I try to compile something, or do somthing else that probably will
  start a major GC, this seems to add to the 200Mb.
  This is strange, because repeated 'Array.array(10000000,1);)
  will not use more than 216Mb.

  Real memory consumption is also large.
Code:
Transcript:
  Example (TOP: means output from the program top):

  GC #0.0.0.0.1.1:   (0 ms)
  Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled]

  TOP:   PID USERNAME PRI NICE   SIZE    RES     COMMAND
  TOP: 16891 toreba    -4    0 19216K  9168K ... run.sparc-sola

  - Array.array(10000000,1);
  GC #0.0.0.0.2.31:   (10 ms)
  GC #0.0.0.1.3.36:   (10 ms)
  val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array

  TOP: 16891 toreba    15    0 59496K 48632K ...

  - Array.array(10000000,1);
  GC #0.0.0.1.4.64:   (1050 ms)
  GC #0.0.0.2.5.72:   (910 ms)
  GC #0.0.0.2.6.85:   (880 ms)
  val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array

  TOP: 16891 toreba   -25    0137800K 127464K ...

  GC #0.0.1.3.7.108:   (1050 ms)
  val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array

  TOP: 16891 toreba    35    0216032K 138544K ...

  - 0;
  GC #0.0.1.3.8.145:   (890 ms)
  val it = 0 : int

  Here, it uses 250MB for a second, and then goes down to 216MB
  No matter what I do here, I can't free much memory.
Comments:
  Probably same as 1131.
Fix:
Test: 
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1120
Title: profiling on Linux
Keywords: profiler
Submitter: Anthony Shipman <als@tusc.com.au>
Date: 1/5/97
Version: 109.22
System: x86/Linux Elf
Severity: major
Problem: 
  I enable profiling with 

      val _ = Compiler.Profile.setMode Compiler.Profile.ACTIVE;

  and the report has 0 for all cumsecs values.
Comments: [JHR, 1/4/97]
  This works for me (Linux 2.0), but I did discover a different
  bug with the reset function:

      <jhr@delenn> sml
      Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled]
      - structure P = Compiler.Profile;
      structure P : PROFILE?
      - P.setMode P.LATENT;
      Creating profiled version of standard library
      val it = () : unit
      - fun f 0 = 1 | f x = (f(x-1); f(x-1));
      val f = fn : int -> int
      - (P.setMode P.ACTIVE; f 15; P.setMode P.NOPROF; P.report TextIO.stdOut);
       %time cumsec #call  name
      100.00    .02 65535  f
      val it = () : unit
      - P.reset();
      val it = () : unit
      - (P.setMode P.ACTIVE; f 20; P.setMode P.NOPROF; P.report TextIO.stdOut);

      uncaught exception SysErr: no count array set
Fix:
Test:
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1121
Title: internal data constructor of abstype is exported
Keywords: abstype, abstract type
Submitter: Cons T Ahs <cons@csd.uu.se>
Date: 1/14/97
Version: 109.23
Severity: major
Problem: 
  The constructor for an abstype is visible outside the abstype
  definition.
Transcript:
  Standard ML of New Jersey, Version 109.23, January 1, 1997 [CM; autoload enabled]
  - abstype foo = bar of int with fun foo x = bar x end;
  type foo
  val foo = fn : int -> ?.foo
  - bar;
  val it = fn : int -> foo
Comments:
Fix:
Test:
Owner: zhong
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1122
Title: secondary error: Compiler bug: InlInfo ...
Keywords: secondary error
Submitter: George Russell <george@persimmon.co.uk>
Date: 1/15/97
Version: 109.24
System: alpha/OSF1 v4
Severity: minor
Problem: secondary compiler bug error message
Transcript:
  - signature a=sig val b:int end abstraction c:a=struct end;
  stdIn:16.31-16.57 Error: unmatched value specification: b
  Error: Compiler bug: InlInfo: Wrong field in INL_STR !
Comments:
Fix:
Test: bug1122.sml
Owner: Zhong
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1123
Title: secondary error: nongeneralizable type variable
Keywords: secondary error
Submitter: Allen Stoughton <allen@cis.ksu.edu>
Date: 1/15/97
Version: 109.24
Severity: minor
Problem: secondary error: nongeneralizable type variable
Transcript:
    - #"a" ^ "a";
    stdIn:12.1-12.11 Error: operator and operand don't agree (tycon mismatch)
      operator domain: string * string
      operand:         char * string
      in expression:
	^ (#"a","a")
    stdIn:12.1-12.11 Error: nongeneralizable type variable
      it : 'Z
Comments:
Fix:
  basics/unify.sml
     Improve the type-checking error messages; fix BUG 1149, 1123
     reported by Allen Stoughton. 
Test:
Owner: dbm
Status: fixed in 109.25.1
----------------------------------------------------------------------
Number: 1124
Title: exception STRANGE raised by compiler
Keywords: modules, functors, printing
Submitter: Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu>
Date: 1/15/97
Version: 109.24
System: alpha32x-osf1
Severity: major
Problem: exception STRANGE raised by compiler
Code: (bug1124.sml)
  signature F =
   sig
    type word
    val u: word
   end

  functor L (structure Base: sig type word end
	     val u: Base.word) =
    struct
      datatype word = W of Base.word
      val u = W u
    end (* struct *)

  structure W': F = L (structure Base = Word32
		       val u = 0w0:word32);

  structure s = W';

Transcript:

  % sml
  Standard ML of New Jersey, Version 109.24, January 9, 1996 [CM; autoload enabled]
  - use "mbug.sml";
  [opening mbug.sml]
  signature F =
    sig
      type word
      val u : word
    end
  functor L : <sig>
  structure W' :
    F?
  printing PATHtyc:[#G85d.8,#G85d.7,#G85d.6] --- word.

  uncaught exception exception STRANGE
    raised at: translate/transtypes.sml:167.22-167.29
	       util/stats.sml:168.40
	       build/evalloop.sml:190.58
	       build/evalloop.sml:272.46-272.49

Comments:
  This case was fixed in 109.25.  But Mikael Pettersson later reported
  the following test case that is still causing the bug in 109.25.

    signature SIG =
      sig
	datatype t1 = C1
	datatype t2 = C2
	and t3 = C3 | C4 of t1
      end;
    functor F(structure S : SIG) =
      struct
	fun f(S.C4 _) = true
	  | f x = x=x
      end;

  Another case reported by Scott Draves is found in bug1124.3.sml.
Fix:
  translate/transtypes.sml
     A temporary fix for the exception STRANGE bug, BUG 1124. A better fix 
     would require the faithful instantiation of datatypes in functor signatures.
Test: bug1124.1.sml, bug1124.2.sml, bug1124.3.sml
Owner: Zhong
Status: fixed in 109.25.1 (temp)
----------------------------------------------------------------------
Number: 1125
Title: Unbound raised instead of proper error for sig inside functor
Keywords: modules, signatures, functors
Submitter: Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu>
Date: 1/17/97
Version: 109.24
System: alpha32x-osf1
Severity: minor
Problem: Unbound raised instead of proper error for a signature
 definition inside a functor body, which is now illegal.
Code: (bug1125.sml)
  functor Tcp () =
  struct
    structure Tcp_Connection =
    struct
      type port = unit
      datatype t = L of {l: port}
    end

    type port = Tcp_Connection.port

    signature LISTEN_EXTENSION =
    sig
      datatype t = L of {l: port}
    end

    structure Listen_Extension:LISTEN_EXTENSION = Tcp_Connection
  end;

Comments:
  This is illegal now, so an appropriate error message should be
  issued for the improper occurrence of the signature declaration.

  Adding "type port = port" to the body of LISTEN_EXTENSION (bug1125.1.sml)
  changes the error to

    Error: Compiler bug: ExpandTycon: expandTycon 2

Fix:
Test: bug1125.sml, bug1125.1.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1126
Title: subscript error in prettyprinting
Keywords: printing, top level
Submitter: Andrew Appel <appel@CS.Princeton.EDU>
Date: 1/21/97
Version: 109.24
System: alpha32x/osf1
Severity: major
Problem: printing nil generates uncaught exception subscript out of bounds.
Code:
  val x = nil

Transcript:
  - val x = nil;

  uncaught exception in compiler: subscript out of bounds
    raised at: print/ppobj.sml:417.28-417.33
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       util/pp.sml:545.6
	       build/evalloop.sml:190.58

Comments:
  Caused by the change in representation of polymorphic constants,
  which are now functions.
Fix:
  print/ppobj.sml
     Fix the pretty-printing bug, BUG 1126 and BUG 1130, on polymorphic 
     constants such as [] and NONE.
Test: bug1126.sml
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1127
Title: TextIO.canInput type does not match Basis Library
Keywords: input, canInput
Submitter: Andrew Appel
Date: 1/21/97
Version: 109.24
System: Alpha / OSF1
Severity: major
Problem: 
  The SML/NJ implementation of TextIO.canInput does not
  match the signature given in the Basis Library documentation.
  I am not sure which one is right.

  SML/NJ:     canInput: instream * int -> int option
  Basis Doc:  canInput: instream * int -> bool
Comments:
  The SML basis documentation is out of date; SML/NJ is correct.
Owner: jhr
Status: not a bug
----------------------------------------------------------------------
Number: 1128
Title: TextIO.canInput raises Io exception WouldBlock
Keywords: input, canInput
Submitter: Andrew Appel
Date: 1/21/97
Version: 109.24
System: alpha-OSF1
Severity: major
Problem: 
  canInput raises an exception if input would block
Transcript:
  - TextIO.canInput(TextIO.stdIn,1);

  uncaught exception Io: canInput failed on "<stdIn>" with exception exception WouldBlock
    raised at: boot/IO/text-io-fn.sml:102.14-102.56
	       boot/IO/text-io-fn.sml:263.29
Comments:
  Please note:  In the following circumstances, canInput seems to be doing
    the right thing (modulo the possible incorrect return type).

  - val f = TextIO.openIn "chap1.sml";
  val f = - : ?.instream
  - TextIO.canInput(f,1);
  val it = SOME 1 : int option
  - TextIO.canInput(f,100);
  val it = SOME 100 : int option
  - TextIO.canInput(f,100000);
  val it = SOME 607 : int option
  - val g = TextIO.openIn "/dev/null";
  val g = - : ?.instream
  - TextIO.canInput(g,1);
  val it = SOME 0 : int option
  - 
Fix: (not tested)
  In text-io-fn.sml, line 263, replace
  BAD:   			    handle WouldBlock => SOME(amount - n))
  GOOD:			handle IO.Io{cause=WouldBlock,...} => SOME(amount-n))

  Make a similar fix on line 257 of bin-io-fn.sml.
Test:
Owner: jhr
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1129
Title: dereference of dangling pointer
Keywords: runtime, memory
Submitter:      Lorenz Huelsbergen (lorenz@research.bell-labs.com)
Date:		1/22/97
Version:        109.* at least
System:         all
Severity:       severe
Problem:        dereference of dangling pointer
Code:           compiling the compiler on win32
Comments:

The file src/runtime/memory/mem-common.ins contains the following
code that dereferences "obj" _after_ having been freed:

/* MEM_FreeMemObj:
 */
void MEM_FreeMemObj (mem_obj_t *obj)
{
    if (obj == NIL(mem_obj_t *))
        return;

    UnmapMemory(obj);

    FREE_MEMOBJ (obj);   

    VMSizeB -= obj->sizeB;

} /* end of MEM_FreeMemObj */

where FREE_MEMOBJ(p) is defined as FREE(p) in memory/mem-mmap.c and
FREE(p) is defined as _FREE(p) in include/ml-base.h and _FREE(p) is
further defined  (also in include/ml-base.h) as the C runtime's "free".

Unfortunately this bug does not reduce memory consumption.  At peak,
compiling the compiler under 109.24 requires >89Mb of memory
(virtual+physical, x86-linux).

Owner: jhr
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1130
Title: printing datatype value
Keywords: printing, datatypes
Submitter: Andrew Wright <wright@research.nj.nec.com>
Date: 1/23/97
Version: 109.24
System: -
Severity: major 
Problem: 
 Printing a value of a datatype at top level causes
 "Compiler bug: PPObj: switch: none of the datacons matched"
Transcript:
  Standard ML of New Jersey, Version 109.24, January 9, 1996
  - datatype ('a,'b) Goo = A of 'a | B of 'b;
  datatype ('a,'b) Goo = A of 'a | B of 'b
  - A 1;
  Error: Compiler bug: PPObj: switch: none of the datacons matched

 Another instance from Mary Fernandez:
  - structure x = struct type ord_key = string val compare= String.compare end;
  - structure y = BinaryMapFn(x);
  - open y;
  open y
  structure Key :
    ORD_KEY?

  uncaught exception in compiler: exception Boxity
    raised at: boot/system.sml:115.27-115.33
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       util/pp.sml:545.6
	       build/evalloop.sml:190.58

 Another instance from Chris Okasaki causing subscript out of bounds:
 - structure L = struct val empty = [] end;
 structure L :
   sig val empty : 'a list end
 - open L;
 open L

 uncaught exception in compiler: subscript out of bounds
   raised at: print/ppobj.sml:417.28-417.33
	      print/ppobj.sml:344.20
	      print/ppobj.sml:344.20
	      util/pp.sml:545.6
	      build/evalloop.sml:190.58

Comments: Related to bug 1126.
 [Zhong Shao: 1/30/97]
  This seems to be related to the bug reported by Andrew. 
  The pretty-printer can't handle polymorphic constants in 109.24.
  For example, 

       val x = nil;

  will trigger the above message too. Polymorphic constants in
  109.24 are represented as functions, i.e., "nil" will be a function
  takes a type value and return 0. I did not figure out a way
  to pretty-print such values yet. 
Fix:
  print/ppobj.sml
     Fix the pretty-printing bug, BUG 1126 and BUG 1130, on polymorphic 
     constants such as [] and NONE.
Test: bug1130.sml
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1131
Title:		Failure to reclaim garbage
Keywords:	garbage collection, arrays, large heaps
Submitter:	Matthias Blume (blume@cs.princeton.edu)
Date:		Jan 26, 1997
Version:	109.19 (probably all 109.*)
System:		x86-linux, alpha-osf1, ... (probably all)
Severity:	major
Problem:	Garbage collector doesn't free up memory previously
		by large arrays.
Code:
		fun listGarbage () = let
		    fun g 0 = [] | g n = 0 :: g (n - 1)
		    val data = g 100000
		in
		    hd data
		end

		fun arrayGarbage () = let
		    val data = Array.array (1000000, 0)
		in
		    Array.sub (data, 0)
		end

		fun loop f = (f (); loop f)
Transcript:
		When running `loop listGarbage;' I get the following
		information from `top' on the DEC Alpha.  The SIZE and
		RES fields settle quickly and then stay the same:

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME    CPU COMMAND
 8902 blume     51    0 25296K 13467K run     0:27 91.30% run.alpha32-os

		When running `loop arrayGarbage;' I get a growing
		heap...

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME    CPU COMMAND
 8902 blume     42    0 25296K 10428K WAIT    1:22  9.80% run.alpha32-os
  PID USERNAME PRI NICE   SIZE   RES STATE   TIME    CPU COMMAND
 8902 blume     45    0 55312K 31948K run     1:30 11.40% run.alpha32-os
  PID USERNAME PRI NICE   SIZE   RES STATE   TIME    CPU COMMAND
 8902 blume     42    0 63120K 33488K run     1:34 17.50% run.alpha32-os
 ...

Comments:
    loop listGarbage;
    runs in constant space -- as one would hope and
    expect. However,
    loop arrayGarbage;
    runs out of virtual memory REALLY quickly, or rather,
    the machine comes to a virtual standstill because of
    the paging.

 [jhr, 1/26/97]
  This is not what is going on.  The garbage is being collected, it is
  a problem the sizing of heaps and VM.  I suspect that if you look at
  the amount of live data in the heap (as opposed to the amount of VM that
  the OS has allocated to the process), you would see constant space.

  These problems should be reduced when the new run-time comes online
  (by the end of Feb, I hope).

 [jhr, 2/19/97]
  I looked into bug #1131, which is the growing heap size when allocating
  large arrays, and I think I understand what is going on.  BTW, there is
  arrayGarbage does roughly 5 times more allocation per call than listGarbage.

  The story is that in the current collector, large arrays are allocated in
  the first generation.  When the first generation gets full, the GC sees that
  the array arena is completely full, and so allocates a somewhat larger arena
  for to-space.  Although only one (or zero) arrays actually get copied to
  to-space, the same thing will happen at the next GC (i.e., the array arena
  will be full and the GC will try to grow it).  While there is a limit on
  the growth of arenas, the minimum size must be large enough to hold all
  the potentially live data plus the extra space neede for the large array
  allocation which triggered the GC.  This is basically a pathological case
  for the current sizing policy, and I don't think that there is an easy fix.
  The new GC will not suffer from this problem, since the to-space memory is
  allocated lazily.

Fix: new runtime
Workaround:
  Force a collection prior to allocation, or periodically
  force two collections in a row.
Test:		
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1132
Title: ExpandTycon 2
Keywords: modules, type constructors
Submitter: Greg Morrisett (jgm@cs.cornell.edu)
Date: Jan. 27, 1996
Version: 109.24
System: Win-NT
Severity: severe
Problem: Compiling the following file causes an uncaught exception
  expandTycon 2.
Code:
  signature FOO = 
    sig
      type TyVar
      structure TVResult:
	sig
	  datatype T = IMP_OK
		     | FAULT of TyVar list
	end
    end;
Transcript:
  - use "test.sml";
  [opening test.sml]
  Error: Compiler bug: ExpandTycon: expandTycon 2

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       elaborate/elabmod.sml:1080.33
	       util/stats.sml:168.40
	       build/evalloop.sml:119.38
	       build/evalloop.sml:190.58
	       build/evalloop.sml:272.46-272.49
Comments:
Fix:
Test: bug1132.sml
Owner: Zhong, dbm
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1133
Title: "<null region>" in non-exhaustive match warning messages
Keywords: error messages
Submitter: John Reppy
Date: 1/29/97
Version: 109.24
System: -
Severity: minor
Problem: 
  I've noticed several "<null region>" regions in non-exhaustive
  match warning messages.  Can we do better than this?
Transcript:
  [compiling ../core-cml/sync-var.sml -> ../core-cml/CM/mipseb-unix/sync-var.sml.bin]
  ../core-cml/sync-var.sml:<nullRegion> Warning: match nonexhaustive
            transId as ref (TRANS tid) => ...
  
This match is in a function binding at the top-level of a structure.
Here is a simple example:

  Standard ML of New Jersey, Version 109.24, January 9, 1996 [CM&CMB 1]
  val it = () : unit
  - structure S = struct
  =     fun f [] = 1
  =   end;
  stdIn:<nullRegion> Warning: match nonexhaustive
            nil => ...
Comments:
Fix:
Test: bug1133.sml
Owner: dbm, zhong
Status: fixed in 109.32 [Andrew, 10/1/97]
----------------------------------------------------------------------
Number: 1134
Title: uncaught exception MapF
Keywords: CM
Submitter: John Reppy
Date: 1/29/97
Version: 109.24+
System: -
Severity: major 
Problem: 
  When trying to compile the latest version of CML on a modified version
  of 109.24, I get the following uncaught exception:

    ...
    [wrote Sockets/CM/mipseb-unix/cml-generic-sock.sml.bin]

    uncaught exception exception MapF
      raised at: env/dynenv.sml:36.30-36.37

  I also checked this with 109.24 and I get the same error.
Comments:
[Matthias]:
  This seems to be due to a bug in the new implementation of
  environments.  Zhong already complained about this.  CM does filtering
  on environments (environment + list of symbols -> new environment only
  containing those bindings from the old one that bind symbols in the
  list) for the case that one uses export filters in CM's description
  files.  This used to work perfectly in pre-109.24 versions, still
  works with static environments, but occasionally runs into the error
  above when dealing with full environments.
[JHR]:
  I just realized that this is this problem with

    structure Foo = CML_Foo

  needing to be rewritten as

    structure Foo = struct open CML_Foo end
Fix:
Owner: Zhong?, dbm
Status: fixed in 109.25.1 [Zhong]
----------------------------------------------------------------------
Number: 1135
Title: CM compiling files that haven't changed
Keywords: CM
Submitter: John Reppy
Date: 2/1/97
Version: 109.25
System: SGI
Severity: major
Problem: 
  I've noticed some unexpected messages from CM recently, where it says
  that it must recompile stuff that I know hasn't changed since it was last
  compiled.  Lal has seen this too.  Here is an example from a clean
  install of 109.25 on an SGI.  The first of these comes during the compile
  of the CML library; the second during the compile of eXene.
Transcript:
  ...
  [recovering ../src/Unix/CM/mipseb-unix/run-cml.sml.bin... failed]
  !% CM Warning: need to recompile ../src/Unix/run-cml.sml (even though it is `stable')
  [compiling ../src/Unix/run-cml.sml (stable) -> ../src/Unix/CM/mipseb-unix/run-cml.sml.bin]
  !* WARNING: ../src/Unix/run-cml.sml (stable) was modified after being analyzed.
  !* -------  (It might be necessary to re-run the analysis.)
  [wrote ../src/Unix/CM/mipseb-unix/run-cml.sml.bin]
  [compiling trace-cml-sig.sml -> CM/mipseb-unix/trace-cml-sig.sml.bin]
  ...
  [starting dependency analysis]
  [dependency analysis completed]
  [recovering ../src/Unix/CM/mipseb-unix/run-cml.sml.bin... failed]
  !% CM Warning: need to recompile ../src/Unix/run-cml.sml (even though it is `stable')
  [compiling ../src/Unix/run-cml.sml (stable) -> ../src/Unix/CM/mipseb-unix/run-cml.sml.bin]
  !* WARNING: ../src/Unix/run-cml.sml (stable) was modified after being analyzed.
  !* -------  (It might be necessary to re-run the analysis.)
  [wrote ../src/Unix/CM/mipseb-unix/run-cml.sml.bin]
  [starting dependency analysis]
  [dependency analysis completed]
Comments:
 [Matthias, 2/1/97]
  I suspect that this is due to some not-quite-synchronized clocks
  between host machine and fileserver, since I am unable to reproduce
  this effect here.

  But I will look into it.
 [JHR, 2/2/97]
  Unlikely, since the machine I was building on is the file server.
  Also, the source file should be days older than the bin file.

  BTW, do you cache timestamps?

 [Matthias, 2/19/97]
  I have the sneaking suspicion that bugs 1106, 1135, and 1154 are
  really all the same bug or at least very closely related.

Test:
Owner: Blume
Status: open
----------------------------------------------------------------------
Number: 1136
Title: sharing causes a type to loose its equality property
Keywords: modules, sharing, equality
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/4/97
Version: 109.25
System: -
Severity: major 
Problem: 
  The new version 109.25 does not inherit eqtype when it is shared
  with a non-eqtype as the following example illustrates. Examples like
  these used to compile under 109.23.
Code:
  signature TS1 = 
  sig
    eqtype t
    val f : t -> t
  end

  signature TS2 = 
  sig
    type t
  end

  functor SF(structure T1:TS1
	     and T2 : TS2
	     sharing type T1.t = T2.t) = 
  struct
    fun test t = T1.f t = t
    fun test ts = List.map T1.f ts = ts 
  end
Transcript:
  - use "bug1136.sml";
  [opening bug1136.sml]
  signature TS1 =
    sig
      eqtype t
      val f : t -> t
    end
  signature TS2 =
    sig type t end
  bug1136.sml:18.16-18.26 Error: operator and operand don't agree (equality type required)
    operator domain: ''Z * ''Z
    operand:         ?.t * ?.t
    in expression:
      = (T1.f t,t)
  bug1136.sml:19.17-19.38 Error: operator and operand don't agree (equality type required)
    operator domain: ''Z * ''Z
    operand:         ?.t list * ?.t list
    in expression:
      = (List.map T1.f ts,ts)

  uncaught exception exception Error
    raised at: build/evalloop.sml:102.44-102.52
	       build/evalloop.sml:119.38
	       build/evalloop.sml:190.58
	       build/evalloop.sml:272.46-272.49

Comments:
Fix:
Test: bug1136.sml, bug1136.1.sml
Owner: dbm
Status: fixed in 109.27 [dbm -- but it is a hack]
----------------------------------------------------------------------
Number: 1137
Title: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
Keywords: modules, functors, sharing
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/4/97
Version: 109.25
System: -
Severity: major
Problem: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
Transcript:
  functor FooFUN(structure CC : CONG_CLOSURE
			  sharing type CC.term = Expr.expr
			  and     type CC.node_type = tyopt)  =
  struct
  end

  Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h
  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:168.40
	       sched/recompile.sml:196.38-196.41

Comments:
 [Bjorner, 2/23/97]
  As noticed earlier, I have not been able to reproduce the bug even when
  uncommenting the code that caused it. (I had avoided the bug by turning
  a functor into a structure and copying it.) Some other  change I made to
  the source must have avoided it. I can therefore not give better indications
  on what causes the bug.
 [Zhong, 2/25/97]
  I ran into another bug today that is most likely the same bug that
  caused the above. I have fixed it in 109.25+, and the code will
  be incorporated into 109.25.1. 

Fix:
Test: 
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1138
Title: undefined signature generates secondary error
Keywords: secondary error
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/4/97
Version: 109.25
System: -
Severity: minor 
Problem: undefined signature leads to "Compiler bug: ModuleUtil: tycId"
  secondary error.
Code:
  functor F(structure T : SIGNOT_DEFINED) = 
  struct
   fun test() = ()
  end
Transcript:
  Error: Compiler bug: ModuleUtil: tycId
Comments:
 [DBM, 2/12/97] I get a different compiler bug:
  - use "bug1138.sml";
  [opening bug1138.sml]
  bug1138.sml:3.25-3.39 Error: unbound signature: SIGNOT_DEFINED
  Error: Compiler bug: Instantiate: lookSlot

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:168.40
	       ...
Fix:
Test: bug1138.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/29/97]
----------------------------------------------------------------------
Number: 1139
Title: Compiler bug: Translate: unexpected type variables in mkPE
Keywords: 
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/4/97
Version: 109.25
System: -
Severity: major
Problem: Compiler bug: Translate: unexpected type variables in mkPE
Code:
  val f = 
    let fun g(t,arg as {a = [],e = e}) c = 
	    let val str = arg
	    in ()
	    end
    in ()
    end

[or, Zhong's version:]

  fun g (arg as [])  = 
      let val str = arg
       in ()
      end

  A temporary get-around will add an explicit type constraint
  after [], e.g. "arg as [] : 'a list".

Transcript:
Comments:
Fix:
  typing/typecheck.sml
     Fix the bug, BUG 1139, on "unexpected type variables in mkPE" reported 
     by Nikolaj (a.k.a. BUG 4 in his list of four bugs for 109.25)
Test: bug1139.1.sml, bug1139.2.sml
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1140
Title: signature decl causes Compiler bug: ExpandTycon: expandTycon 2
Keywords: modules, signatures
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 1/14/97
Version: 109.24
System: -
Severity: major 
Problem: 
  Compiling a signature declaration causes "Compiler bug: ExpandTycon:
  expandTycon 2".
Code: (reduced by Zhong Shao)
  signature BUTTON_VECTOR =
  sig
    type key
    structure R : 
      sig
	datatype s = Toggle of key
      end
  end 
Transcript:
  - use "bug1140.sml";
  [opening bug1140.sml]
  Error: Compiler bug: ExpandTycon: expandTycon 2

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       elaborate/elabmod.sml:1080.33
	       util/stats.sml:168.40
	       build/evalloop.sml:119.38
	       build/evalloop.sml:190.58
	       build/evalloop.sml:272.46-272.49

Test: bug1140.sml
Owner: Zhong, dbm
Status: fixed in 109.25
----------------------------------------------------------------------
Number: 1141
Title: functor decl produces Compiler bug: ExpandTycon: expandTycon 2
Keywords: modules, functors
Submitter: Zhong Shao
Date: 2/13/97
Version: 109.25
System: -
Severity: major
Problem: 
  Compiling a functor decl causes "Compiler bug: ExpandTycon: expandTycon 2".
Code:
Transcript:
  - use "bug1141.sml";
  [opening bug1141.sml]
  Error: Compiler bug: ExpandTycon: expandTycon 2

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       elaborate/elabmod.sml:993.8
	       elaborate/elabmod.sml:1209.7
	       elaborate/elabmod.sml:1097.33
	       ...
Comments:
  This is a variant of the code in bug 1125.
Fix: [dbm] added entEnv parameter to expandTycon.
Test: bug1141.sml
Owner: Zhong, dbm
Status: fixed in 109.25.1 [dbm]
----------------------------------------------------------------------
Number: 1142
Title: size of exportFn image
Keywords: exportFn, image size
Submitter: Tore Jahn Bastiansen <toreba@ifi.uio.no>
Date: 2/4/97
Version: 109.25
System: sparc/solaris
Severity: major
Problem: 
  exporftFn image size increased dramatically between 109.22 and 109.25.
  I have been using both versions 109.22 and 109.25 on sparc-solaris.
  When compiling with 109.25 the heap image generated by 
  SMLofNJ.exportFn seems to be a lot bigger:

  109.25
  -rw-r-----   1 toreba    9913224 Feb  4 10:05 abel.sparc-solaris

  109.22
  -rw-r-----   1 toreba    1267888 Feb  4 10:22 abel.sparc-solaris

  BTW. I also get small differences on an UltraSparc compared to 
  a Sparc-20. Even when the runtime and library sources are exactly the
  same and no compiling is done (only recovering and linking via CM).

  ==========
  Also noted by Peter Bertelsen (pmb@dina.kvl.dk):

    SMLofNJ.exportFn("dummy", fn (rt, args) => OS.Process.success) : unit;

  Even a trivial function like the one exported above produces a huge
  heap image (a bit larger than the original heap image for the entire
  compiler):

	  dummy.x86-linux :	8942172 bytes

	  sml-cm.x86-linux :	8724948 bytes

Transcript:
Comments:
 [jhr]The implementation of exportFn is tricky (making sure that everything
  that everything that is not needed is stripped away).  We must have
  broken something in going from 109.22 to 109.25.  Did you try your
  program with 109.23 or 109.24 by any chance?
 [jhr, with regard to UltraSparc/Sparc-20 differences]
  Have you tried both orders (i.e., compile on SS20 and then load on
  US vs. compile on US and load on SS-20)?

 [Zhong]
  I checked your code on my sparc 20, it seems to work out ok with the
  bare sml or sml-cm compiler (See attached, the image is about
  0.6Mbytes).

  I did see the problem if I run "sml" with CML loaded, it looks like
  that when we do exportFn, we are also exporting all the newly loaded
  environment (from CM). We'll fix this in the next release.

 [Mathieas]
  > You are the second person to report this bug.  Clearly, something was broken
  > in the 109.24, but I don't know what.  I'm also curious as to why CML stuff
  > is being autoloaded, when you haven't mentioned CML.

  He _did_ mention it: CML exports a structure OS.

 [jhr]
  |> In message <199702061723.SAA03299@ellemose.dina.kvl.dk>, Peter
  |> Michael Bertelsen wri tes:
  >>
  >> > You are the second person to report this bug.  Clearly, something
  >> was broken > in the 109.24, but I don't know what.  I'm also
  >> curious as to why CML stuff > is being autoloaded, when you haven't
  >> mentioned CML.
  >> 
  >> I requested AUTOLOAD_CML when the compiler was built; didn't know that
  >> this would make a difference.  As for the huge images, I have now
  >> tried to rebuild the compiler without CML; this brings the image size
  >> for the trivial `dummy' example down to 652k (on Linux).
  |>
  |> So what is happening is that the reference to OS.Process is being viewed as
  |> a reference to CML's version of that.  Even without the CML stuff, this
  |> image is twice as large as in 109.23.

 [Zhong]
  In 109.24, I have temporarily turned off the structure-access lifting;
  this seems to be a bad idea. 

  For a function such as 

    fun f x = OS.Process.success

  in 109.24, the closure for "f" would contain a reference to the entire
  structure OS rather than to the actual field "OS.Process.success", thus 
  leading to the leak above.

Fix:
  translate/translate.sml
    Putting back the access-lifting code to avoid the "exportFn image blowup"
    bug --- BUG 1142. 
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1143
Title: Word.andb combined with toInt broken on x86
Keywords: Word, x86
Submitter: Manuel Fahndrich <manuel@cs.berkeley.edu>
Date: 04/02/97
Version: 109.25
System: x86/Linux
Severity: major
Problem: Word.andb followed by Word.toString gives wrong answer
Code:
  val maskr = ref 0wx3fff;
  Word.andb (!maskr, 0wxfffffff);
  Word.toInt (Word.andb (!maskr, 0wxfffffff));

Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled]
  - val maskr = ref 0wx3fff;
  val maskr = ref 0wx3fff : word ref
  - Word.andb (!maskr, 0wxfffffff);
  val it = 0wx3fff : word
  - Word.toInt (Word.andb (!maskr, 0wxfffffff));
  val it = ~1073725441 : int

Comments: Works without the explicit dereference.
  [Zhong]This seems to be caused by something in the implementation of 
  the new "testu_31_31" primop. It works in version 109.15 (which
  uses realu31_i31 primop) but fails in 109.22 (which uses the
  testu_31_31 primop) to do the Word.toInt conversion.

  ========================
  [Lal] testu_31_31 looks correct. There appears to be some interaction with
  references that triggers this bug, because:

	  val x = 0wx3fff;
	  Word.toInt x;

  gives the correct answer, but:

	  val x = ref 0wx3fff;
	  Word.toInt (!x); 

  generates a wrong answer. This bug does not occur on the alpha or
  hppa, so it must be code generator related.

  =======================
  [jhr] It fails in 109.23 on the MIPS, so I suspect that it is a bug in generic.

  =======================
  [Lorenz] It first appears in the transition from 109.17 to 109.18.
  Here's a simpler test:

  - fun f x = Word.toInt x;
  val f = fn : word -> int
  - f 0w0;
  val it = ~1073741824 : int
  - Word.toInt 0w0;
  val it = 0 : int
  - 

  I suspect contract.sml, in particular the lines (in 109.25):

     | PURE(P.copy(p,n), [v], x, t, e as ARITH(a, [v2], x2, t2, e2)) => let
	 val v' = [ren v]
	 fun skip () = PURE(P.copy(p,n), v', x, t, g' e)
	 fun checkClicked(tok, n2, m, class, arithOp) = 
	   if cvtPreCondition(n, n2, x, v2) then
	     (click tok; class(arithOp(p,m), v', x2, t2, g' e2))
	   else skip()
       in
	 case a
	  of P.test(n2,m) =>
	     if m >= p then checkClicked("C5", n2, m, PURE, P.copy)
	     else checkClicked("C6", n2, m, ARITH, P.test)
	   | P.testu(n2,m) => 
	     if m >= p then checkClicked("C7", n2, m, PURE, P.copy)
	     else checkClicked("C8", n2, m, ARITH, P.testu)
	   | _ => skip()
       end

  I read this as: "a P.copy followed by a P.testu will remove the testu
  if the copy contains the size of the testu args (and some other stuff)."  
  I don't see why it's safe to remove an overflow check here.  What invariant 
  guarantees that this check gets done elsewhere?  
  Note that (p = n = n2 = m = 31) will remove the testu. 

  Before compiling a compiler that changes this (see my next sml-bugs message)
  to see if it's indeed the bug, perhaps the writer of this code would be
  so kind to check my reading of it.

  =======================
  [Lal] Well, the bug is really in the mips code generator.
  testu_31_31 is implemented in generic as:

	| ARITH(P.testu(31, 31), [v], x, _, e) => 
	      alloc(x,any,fn x' => let val vreg = gpregbind v
		    in
		      M.addt(vreg,gpregbind(INT32 0wx80000000), x');
		      M.move(vreg, x');
		      gen e
		    end)

  The M.addt traps on overflow and does the necessary range check. 

  If no overflow takes place, then the M.move copies the argument (vreg)
  into the result register x'. However, The implementation of M.move
  among other things has something like this:

    fun move(Direct a, Direct b) =
     (case (reg_rep a, reg_rep b) 
       of   ....
	| (Reg' a', Reg' b') => 
	       if a'=b' then () else emit(M.ADD(b,a,RegOp0)))
	    ....

  Now if vreg is identical to x', then the copy is _not_ performed!!
  Hence the bug.
						  QED.
  ======================
  [Lorenz]
  >> Zhong wrote:
  >> >> > This seems to be caused by something in the implementation of 
  >> >> > the new "testu_31_31" primop. It works in version 109.15 (which
  >> >> > uses realu31_i31 primop) but fails in 109.22 (which uses the
  >> >> > testu_31_31 primop) to do the Word.toInt conversion.
  >> 
  >
  >> Lal responds:
  >> >> testu_31_31 looks correct. 
  >> >> 
  >
  >> John says:
  >> >It fails in 109.23 on the MIPS, so I suspect that it is a bug in generic.
  >
  >> Lorenz writes:
  >> It first appears in the transition from 109.17 to 109.18.
  >> Here's a simpler test:
  >
  >Well, the bug is really in the mips code generator.

  Well, then its in the other old code generators as well.
  Moreover, I don't think it's a CG bug...

  >testu_31_31 is implemented in generic as:
  >
  >      | ARITH(P.testu(31, 31), [v], x, _, e) => 
  >	    alloc(x,any,fn x' => let val vreg = gpregbind v
  >		  in
  >		    M.addt(vreg,gpregbind(INT32 0wx80000000), x');
  >		    M.move(vreg, x');
  >		    gen e
  >		  end)
  >
  >The M.addt traps on overflow and does the necessary range check. 
  >
  >If no overflow takes place, then the M.move copies the argument (vreg)

  because what else should M.move do if the src and dst are the same?
  If it did the explicit move, that would have the same deleterious effect here.

  Are we certain that it's OK for generic to see a primop where the 
  args and the destination share a common lvar?  

  The question seems to be: why is testu(31,31) being passed an 
  arg (v) that maps to the same register as its destination.


  >into the result register x'. However, The implementation of M.move
  >among other things has something like this:
  >
  >  fun move(Direct a, Direct b) =
  >   (case (reg_rep a, reg_rep b) 
  >     of   ....
  >      | (Reg' a', Reg' b') => 
  >	     if a'=b' then () else emit(M.ADD(b,a,RegOp0)))
  >          ....
  >
  >Now if vreg is identical to x', then the copy is _not_ performed!!

  Again, how would you correctly _do_ the copy in the CG if dst == src?

  >Hence the bug.
  >						QED.

  Not convinced,
  Lorenz

  ===================
  [Lal]
  > Date: Wed, 05 Feb 1997 16:39:20 -0500
  > From: Lorenz Huelsbergen <lorenz>
  > ...
  > I read this as: "a P.copy followed by a P.testu will remove the testu
  > if the copy contains the size of the testu args (and some other stuff)."  
  > I don't see why it's safe to remove an overflow check here.  What invariant 
  > guarantees that this check gets done elsewhere?  
  > Note that (p = n = n2 = m = 31) will remove the testu. 

  Indeed this is a bug. 
  The rules relating TESTU and COPY should be:

    TESTU(n,m) o COPY(p,n)	== COPY(p,m)   if (m > p)
				  == TESTU(p,m)  if (m <= p)	
  ==============
  [Lorenz]
  Here is list of potential instances of the alloc/gpregbind bug
  in cps/generic.sml:

	  | ARITH(P.testu(32, 32), [v], x, _, e) => 
		alloc(x,any,fn x' => let val vreg = gpregbind v
		      in
			M.addt(vreg,gpregbind(INT32 0wx80000000), x');
			M.move(vreg, x');
			gen e
		      end)

	  | ARITH(P.testu(31, 31), [v], x, _, e) => 
		alloc(x,any,fn x' => let val vreg = gpregbind v
		      in
			M.addt(vreg,gpregbind(INT32 0wx80000000), x');
			M.move(vreg, x');
			gen e
		      end)

	  | ARITH(P.testu(32,31), [v], x, _, e) => 
		alloc(x, any, fn x' => let 
	                   val vreg = gpregbind v
			   val lab = newlabel()
		         in
			   ibranch(LEU, vreg, gpregbind(INT32 0wx3fffffff), lab);
			   M.move(gpregbind(INT32 0wx80000000), x');
			   M.addt(x', x', x');
			   define lab;
			   M.add(vreg, vreg, x');
			   M.orb(immed 1, x', x');
			   gen e
			 end)

	  | PURE(P.pure_arith{oper=P./,kind=P.UINT 32},[v,w],x,_,e) => 
		 alloc(x,any,fn x' => 
		       (M.move(gpregbind v,x');
			M.divtu(gpregbind w,x');
			gen e))

	  | ARITH(P.arith{oper=P./,kind=P.INT 32},[v,w],x,_,e) => 
		 alloc(x,any,fn x' => 
		       (M.move(gpregbind v,x');
			M.divt(gpregbind w,x');
			gen e))


  =====================
  [Lal]
  Actually there are more bugs of this kind lurking around particularly
  wrt to M.mult, M.mulu, and M.divtu. I'm amazed that we haven't tripped
  over them before. The fix for this is a little involved. There are two
  alternatives:

    1. Change M.divt (and others) to be 3-address instructions. This
       would mean changing the implementation in all the code generators.

    2. Gurantee at least two arithmetic temps. This may not be such 
       a big problem on RISC machines (although it would be a shame 
       to tie up a register this way), but would certainly hurt the
       x86.

  =====================
  [jhr]

    3. switch to the new back-end.

  =====================
  [Lorenz]
  >Actually there are more bugs of this kind lurking around particularly
  >wrt to M.mult, M.mulu, and M.divtu. I'm amazed that we haven't tripped

  The primops with M.mult, M.mulu, and M.divtu (other than the above)
  seem OK since they use arithtemp.  The problem occurs when there's a
  write to the alloc'd variable (x') before the last gpregbind of a variable
  since (as you pointed out) alloc is free to use the same register as 
  that assigned to another lvar as long as the last use appears in this
  expression.

Fix:
Test: bug1143.sml
Owner: Lal
Status: fixed in 109.25.1 (Lal)
----------------------------------------------------------------------
Number: 1144
Title: exception Compile: "imported objects not found or inconsistent"
Keywords: modules, structures, open
Submitter:      Elsa L. Gunter
Date:           5 February 1997
Version:        109.25
System:         linux, version 2.0
Severity:       critical
Problem:        If you create a structure with a nested substructure, and then
                create another stucture with the first as a substructure, and
                then open the second and the refer to a component of the
                substructure of the first, the compiler finds inconsistent
                (or non-existant) objects.
Code:
(* File: bug1144.sml *)
  structure B = struct structure A = struct fun f () = () end end;
  structure C = struct structure B = B end;
  open C;
  fun t () = B.A.f;

Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled]
  - use "bug1144.sml";
  [opening bug1144.sml]
  structure B :
    sig structure A : <sig> end
  structure C :
    sig structure B : <sig> end
  open C
  structure B :
    sig structure A : <sig> end
  lookup 2f2acba603a0e9885fba5cbf83aaadd3
  lookup fc03a1bf80706210bdd10474b667dfff

  uncaught exception Compile: "imported objects not found or inconsistent"
    raised at: build/compile.sml:39.20-39.31
	       util/stats.sml:168.40
	       build/evalloop.sml:190.58
	       build/evalloop.sml:272.46-272.49

Comments:
  Both the open and the semicolons are important.
Fix:
  pickle/pickmod.sml
     Turn off the sharing of the structure bindings, because structures
     with same modids may potentially have different dynamic accesses.
     This fixed BUG 1144 reported by Elsa Gunter.
  [dbm] This fix may have an unfortunate effect on the size of static
   environments.  A better permanent fix involves separating the
   dynamic access field from the static structure, functor representations.
Test: bug1144.sml
Owner: Zhong, dbm
Status: fixed in 109.25.1 (temp?) (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1145
Title: large memory consumption
Keywords: memory, performance
Submitter:      Lorenz Huelsbergen (lorenz@research.bell-labs.com)
Date:		2/5/97
Version:        109.24, 109.25
System:         mipseb-irix5, x86-win32, presumably all
Severity:       major
Problem:        large memory consumption
Code:           compiling the compiler
Comments:

When compiling the compiler for versions 109.24 and 109.25, the following
amounts of real and virtual memory are used:

		109.24 x86-win32	109.25 x86-win32

real:		101 MB			150 MB
virtual:	166 MB			199 MB

These numbers come via the NT performance monitor, which can gather,
among other things, per-process peak real and virtual memory usage.
The virtual-memory numbers are the number of virtual bytes reserved
by the process, but not necessarily allocated.

On mipseb-irix5, the process sizes grow to:

		109.24 mipseb-irix5	109.25 mipseb-irix5

"top"'s size:	139 MB			154 MB

The mipseb-irix5 numbers were obtained by staring, for the length of
the compile, at the output of "top," recording the largest value for 
the process "size" field, and multiplying by the OS's page size (4K).

Default compiler/runtime settings were used.

I'm sending this along as a major bug since it impedes coding as much, 
if not more, than an incorrect implementation of a compiler component 
(which often has a source-level work around).

[jhr] I think that this can be traced to the reformat phase (at least we have
some strong evidence of that).  I assume that Zhong is working on a fix.

Fix: [Zhong]
Enclosed please find a (temporary) fix for the "reformat" bug John 
mentioned above. The "crazy" space blowup can occur only if you are
compiling abstractions (with huge mutually recursive datatypes). In
the compiler, all the space blowup happens when compiling the
file profile/tell-env.sml. 

  basics/typesutil.sml
     Turn off the reformating on abstract data types. Reformating can
     potentially leads to exponential space and time blow up (BUG 1145).

[dbm]
This is a temporary fix.  A long term fix requires redesign of the
datatype representation.

Owner: Zhong
Status: fixed in 109.25.1 (temp)
----------------------------------------------------------------------
Number: 1146
Title: core dump on x86/linux
Keywords: core dump
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 2/4/97
Version: 109.25
System: x86-linux
Severity: critical
Problem: 
  I include this file using use "nines.sml", something magically auto-loads
  the sml-nj library (cool), but the program dumps core after about a minute
  and a half on a Pentium 133:

  - Problem.dumpCore();
  /usr/local/src/smlnj-109.25/bin/.run/run.x86-linux: Fatal error -- unexpected fault, signal = 11, code = 0x804cdab

  The machine has 80M of real memory and 80M of swap -- I don't think it's
  running out of memory, but you never know...  
Code: bug1146.sml
Transcript: 
Comments:
 [jhr, 4/3/97]
  This bug has something to do with floating-point.  The program he sent goes
  off in bad ways because of NaNs (which he did not expect), but there was also
  a problem with a bogus floating-point exception code being generated by Linux
  (it doesn't actually dump core).
Fix:
Test: bug1146.sml
Owner: Lorenz
Status: fixed in 109.27 [Lorenz, 4/11/97]
----------------------------------------------------------------------
Number: 1147
Title: "where type" causes nonexhaustive match failure
Keywords: modules, signatures, where type
Submitter: Chris Okasaki <Chris_Okasaki@terrier.fox.cs.cmu.edu>
Date: 2/6/97
Version: 109.25
System: -
Severity: major 
Problem: 
  Trying to use the "where type" syntax in 109.25 causes a
  nonexhaustive match failure.
Transcript:
  - signature S = sig type T end;   
  signature S =
    sig type T end
  - signature S' = S where type T = int;

  uncaught exception in compiler: nonexhaustive match failure
    raised at: decl/convert.sml:189.25
	       build/evalloop.sml:190.58

Comments:
  [Mathias] This looks like it is coming from CM.  Whoever patched it for use with
  the new front end must have left out a few cases...
Fix:
Test: bug1147.sml
Owner: dbm, Matthias
Status: fixed in 109.25.2 [Matthias]
----------------------------------------------------------------------
Number: 1148
Title: ALPHA32.PRIM.ASM floor_a still uses unimplemented instruction
Keywords: Real, floor_a
Submitter:  Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu>
Date: 2/7/97
Version: 109.25
System: alpha-osf1
Severity: minor
Problem: 
  floor_a in 109.25 uses an addt/m instruction which, like the cvtqlv it
  replaced, is not implemented by the processors in our alphastations
  250 4/266 workstations.  With the latest firmware and OSF1, executing
  the addt/m instruction generates a SIGILL signal, resulting in a core
  dump.

  This instruction is presumably emulated by other firmware/OS
  combinations, but this makes the addt/m instruction very costly to
  execute.
Comments:
Fix:
  Here's the version of floor_a we use.  It is ugly, and its use of the
  stack is suspect, but something along these lines should be
  acceptable.

  ML_CODE_HDR(floor_a)
	  ldt	$f0,0(STDARG)		/* get argument */
	  fblt	$f0, 2f			/* jump if argument is negative */
	  cvttqvc	$f0,$f0			/* round to quadword */
	  cvtqlv	$f0,$f0			/* convert quad to long */
	  sts	$f0,-4($30)		/* store temporarily into C stack */
	  ldl	ATMP1,-4($30)		/* load from C stack */
	  addlv	ATMP1,ATMP1,ATMP2	/* make room for tag bit */
  1:	bis	ATMP2,1,STDARG		/* add the tag bit */
	  CONTINUE
  2:	/* negative argument */
	  /* cvttqm (x) = cvttq (2*x - 0.5) / 2 */
	  /* cvttq (x-0.5) loses for odd integers which IEEE round to evens */
	  lda	$0,0xC1E0000000000000	/* t-floating -2147483648.0 ... */
	  stq	$0,8(sp)		/*  ... (minimum 31 bit signed int) */
	  ldt	$f1, 8(sp)		/* load min into $f1 */
	  subt	$f0, $f1, $f1		/* is arg too small? */
	  fblt	$f1, 3f			/* jump if yes (underflow) */
	  lda	$0,0x3FE0000000000000 	/* t-floating -0.5 */
	  stq	$0,8(sp)		/* move via stack ... */
	  ldt	$f1, 8(sp)
	  addt	$f0, $f0, $f0		/* compute ... */
	  subt	$f0, $f1, $f0		/*  ... 2*x + 0.5 */
	  cvttq	$f0, $f0		/* round to int */
	  stt	$f0, -8($30)		/* move via stack ...
	  ldq	STDARG, -8($30)
	  sra	STDARG, 1		/* halve */
	  br	1b
  3:	eqv	STDARG, STDARG, STDARG /* generate overflow */
	  sll	STDARG, 63, STDARG
	  addqv	STDARG, STDARG, STDARG
	  trapb
	  CONTINUE
Comment: same as bug 1097
Test:
Owner: Lal
Status: fixed in 109.25.1 (Lal)
----------------------------------------------------------------------
Number: 1149
Title: spurious "nongeneralizable type variable" messages
Keywords: type checking, value restriction
Submitter: Allen Stoughton <allen@cis.ksu.edu>
Date: 2/7/97
Version: 109.25
System: -
Severity: minor 
Problem: 
  The spurious "nongeneralizable type variable" messages haven't completely
  disappeared in 109.25, as the following example shows:
Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997
  - fun f(x, y) = x ^ y;
  val f = fn : string * string -> string
  - f "a" "b";
  stdIn:8.1-8.10 Error: operator and operand don't agree (tycon mismatch)
    operator domain: string * string
    operand:         string
    in expression:
      f "a"
  stdIn:8.1-8.10 Error: nongeneralizable type variable
    it : 'Z
Comments:
Fix:
  basics/unify.sml
     Improve the type-checking error messages; fix BUG 1149, 1123
     reported by Allen Stoughton. 
Test: bug1149.sml
Owner: dbm, Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1150
Title: secondary error - Compiler bug: ModuleUtil: fctId
Keywords: modules, secondary
Submitter: Mikael Pettersson (mpe@ida.liu.se)
Date: 02/10/97
Version: 109.25
System:	-
Severity: minor
Problem: calling nonexistent functor apparently doesn't abort compilation
Code:		
Transcript:	

- structure S = F();
stdIn:16.15-16.18 Error: unbound functor: F	(* ok *)
Error: Compiler bug: ModuleUtil: fctId		(* huh? *)

Comments:	
  This causes a different error (nonexhaustive match failure in
  modules/sigmatch:844.5) in 109.23.
Fix:
Test: bug1150.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/29/97]
----------------------------------------------------------------------
Number: 1151
Title: equality on reals admitted
Keywords: equality, reals
Submitter: Andrew Kennedy <andrew@persimmon.co.uk>
Date: 2/11/97
Version: 109.25
System: -
Severity: major 
Problem: equality operation on reals is admitted without complaint.
Transcript:
  - fun f (x,y) = (x/y, x=y);
  val f = fn : real * real -> real * bool
Comments:
Fix:
Test: bug1151.sml
Owner: dbm, jhr
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 1152
Title: opaque signature matching with sharing looses equality property
Keywords: modules, signatures, sharing, equality
Submitter: George Russell <george@persimmon.co.uk>
Date: 2/11/97
Version: 109.25
System: -
Severity: major 
Problem: 
  If a type with an eqtype spec shares with a non-equality type
  in an opaque signature match, the first type looses its equality
  property.
Code:
  (* bug1152.1.sml *)
  structure A :> 
    sig
      eqtype t
    end =
  struct
    type t = int
  end;

  fun f(x: A.t) = x = x;  (* works *)
=========================
  (* bug1152.2.sml *)
  structure A :> 
    sig
      eqtype t
      structure B: sig type t end
      sharing type t = B.t
    end =
  struct
    type t = int
    structure B = struct type t = t end
  end;

  fun f(x: A.t) = x = x;  (* should work, but doesn't *)

Comments:
  [dbm]. This is the same bug as 1136.
Fix: Each instance type should keep the same eqprop as it's spec. I believe
  this is the behavior specified in SML 96.
Test: bug1152.sml
Owner: dbm, Zhong
Status: fixed in 109.27 [dbm -- but it is a hack]
----------------------------------------------------------------------
Number: 1153
Title: core dump
Keywords: core dump
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 2/11/97
Version: 109.25
System: sparc Ultra 2/Solaris
Severity: critical
Problem: 
  I managed to make sml 109.25 dump core. Would you like to 
  see the core image:

  -rw-rw----   1 nikolaj  76368852 Feb 11 08:55 core

  I ran it with some debugging (TraceCML.xspawn) explaining the
  other printouts on the run.

Code:
Transcript:
  WARNING!  Watched thread Color.getColor[006152] has died.
  xspawn Color.getColor [006156]
  thread Color.getColor [006154]exiting.
  xspawn Color.getColor [006158]
  thread Color.getColor [006156]exiting.
  WARNING!  Watched thread Color.getColor[006154] has died.
  xspawn Color.getStipple [006160]
  thread Color.getStipple [005984]exiting.
  WARNING!  Watched thread Color.getColor[006156] has died.
  xspawn Color.getColor [006162]
  thread Color.getColor [006158]exiting.
  WARNING!  Watched thread Color.getStipple[005984] has died.
  xspawn Color.getColor [006164]
  WARNING!  Watched thread Color.getColor[006158] has died.
  thread Color.getColor [006162]exiting.
  WARNING!  Watched thread Color.getColor[006162] has died.
  xspawn Color.getColor [006166]
  thread Color.getColor [006164]exiting.
  WARNING!  Watched thread Color.getColor[006164] has died.
  Illegal Instruction - core dumped
  manet> 
Comments:
 [jhr]
  I ran the heap image you sent me under adb, and it looks like
  it might be a bug in the new representation analysis (not my
  part of the system :).  I will continue to look into the
  unexpected shutdown problem, which I suspect is unrelated.

  Zhong: there is a fairly repeatable SIGBUS error on the
  sparc in a big CML/eXene program.  The code being executed is:

	  bl      noGC
	  sub     %g1, -0xaf8, %i3
	  ld      [%sp+0x64], %o4
	  mov     %g1, %o7
	  jmp     %o4
	  mov     0x7f, %o5
  noGC:
	  ld      [%i0+0x4], %o1		// SIGBUS here
	  ld      [%o1], %i0
	  jmp     %i1
	  cmp     %g6,%g4

  The value of %i0 is 0xb6206fff, which is a tagged int/word.
  I ran this twice and got the same error (same register value)
  at the same address.

 [jhr]
  In message <199702132154.QAA11393@daffy.systemsx.cs.yale.edu>, Zhong Shao writes:
  >
  > 
  > |> Tracing things down in the source-code will take some time 
  > |> as I am chasing a couple of conference deadlines the next weeks. 
  > |> We also have not bundeled up the code so it is ready-to-go.
  > |> I am not sure about what you mean by 
  > |> "exportML a version of the compiler right before".
  > |>
  > |> nsb
  > 
  > I mean "export" a binary version of the compiler (by calling
  > SMLofNJ.exportML).

  This is not practical in this case.  The program in question is an
  eXene application.  It doesn't run very long before it core dumps
  (two menu operations).

 [jhr, 2/20/97]
  This causes a bus error on the SGI as well.

Fix:
  translate/wrapping.sml
  translate/ltycomp.sml
  translate/ltyprim.sml
    Fixing the incorrect wrapper bug, BUG 1158, reported by Ken Cline 
    (zcline.sml). This also fixes the core dump bug, BUG 1153,
    reported by Nikolaj. 
Test:
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1154
Title: CM insists on recompiling sources in a stable library
Keywords: CM, cutoff recompilation
Submitter: Matthias Blume <blume@CS.Princeton.EDU> 
Date: 2/12/97
Version: 109.25
System: -
Severity: major 
Problem: 
  I just spent some time chasing a particularly persistent bug:
  Both Lal and John reported earlier that CM would insist on
  recompiling certain sources, despite the fact that the library they
  are in is stable and none of the sources were touched in between.

  However, after fixing a bug in my treatment of timestamps - something
  that I hoped would solve the problem - the effect did _not_ go away.
  I investigated further, and now it looks very much like a bug related
  to hashing and/or filtering of environments.

  Let me explain: The context for compiling or unpickling a given
  compilation unit is constructed by combining the delta environments
  obtained from compiling/unpickling its predecessors in the dependency
  graph.  Some of those predecessors may live in a group/library that
  has an export filter.  In this case the corresponding delta env is
  filtered first before it is used and its hash is (re)calculated for
  the purpose of compatibility checks.

  Unfortunately, for some reason the following property doesn't seem to
  hold in (at least) 109.25 (remember that pickling/hashing is always
  done relative to some context):

	  hash{env=c,context=empty) = hash(env=c',context=empty)
	      hash(env=e,context=c) = hash(env=e',context=c')
				  f = f'
    --------------------------------------------------------------------
    hash(env=filter(e,f),context=c) = hash(env=filter(e',f'),context=c')

  In words:  Hashing the _same_ delta environment filtered by the _same_
  filter with respect to the _same_ context yields _different_ hash
  values.  And the effects are spurious recompilations...

  Environment gurus: Any ideas what's going on?

Comments:
 [Andrew]
  I don't know what's going on, but I will be happy to sit down with you
  and we can instrument the pickler to report what the difference
  is between one thing and the other, so that we can track it down.

 [Matthias, 2/13/97]
  The function Signature in pickle/pickmod.sml pickles boundeps, even
  though a comment says it doesn't.  Unfortunately, in what should be
  _exactly_ the same environment it sometimes is

	  ref NONE

  and at other times

	  ref (SOME <list>)

  Thus, the pickles and therefore the hash value come out differently.
  We once had the same problem with lty, and I went through some pretty
  ugly hackery to fix that.

  In general I would like to see all optional information that is
  redundant (not sure if boundeps is redundant) disappear completely
  from the pickled environments, because it only causes trouble there.

 [Zhong, 2/13/97]
  I was in charge of the "boundeps" stuff in Signature --- the "boundeps"
  itself is a hack, it should become standard (not an "option ref" anymore) 
  once the module instantiation is implementated incrementally.

  For the time being, you can turn off the pickling of the boundeps field
  completely. Would this fix your unnecessary recompilation problem ?

 [Matthias, 2/19/97]
  I have the sneaking suspicion that bugs 1106, 1135, and 1154 are
  really all the same bug or at least very closely related.

 [Zhong, 2/20/97]
  The "boundeps" field could be one cause for bug 1154, but
  it cannot be the cause for 1106 since signatures in 109.21
  do not even haven boundeps field.

Fix:
  [Zhong, 2/26/97]
  pickle/pickmod.sml
     Turn off the pickling on the boundeps field of the signatures. 
     If Matthias's analysis is right, this could fix BUG 1154. But
     I think there are other reasons to BUG 1154.
Test:
Owner: Andrew, Matthias
Status: open
----------------------------------------------------------------------
Number: 1155
Title: type abbreviation identical to spec does not match (+ secondary)
Keywords: modules, signature matching
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 2/13/97
Version: 109.25
System: -
Severity: major? 
Problem: 
  After a couple signature matching error messages, "Compiler bug:
  TypesUtil: tycStamp ERRORtyc" is generated.
Code:
  signature S1 =
  sig
    type s
  end;

  signature S2 =
  sig
    structure A : S1
    type t = A.s
  end;

  functor G(Y: S2) =
  struct
    open Y
  end;

  functor H(Z: S1) = 
  struct
    structure B =
      struct
	structure A = Z
	type t = A.s	
      end
    structure C : S2 = G(B)
  end;

Transcript:
  - use "bug1155.sml";
  [opening bug1155.sml]
  signature S1 =
    sig type s end
  signature S2 =
    sig
      structure A : sig type s end
      type  t = A.s
    end
  functor G : <sig>
  bug1155.sml:24.3-24.26 Error: type t does not match definitional specification
  bug1155.sml:24.3-24.26 Error: unmatched type specification: t
  Error: Compiler bug: TypesUtil: tycStamp ERRORtyc

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:168.40
	       elaborate/elabmod.sml:993.8
	       elaborate/elabmod.sml:1209.7
	       elaborate/elabmod.sml:1097.33
	       ...
Comments:
 [Ramsey, 2/19/97]
  Looks secondary to me too.  The problem is, *I* think the code is good,
  and the code compiles without any error at all under 109.23.  So
  either there's a primary error triggering all this, or else you've
  implemented another of those rules of SML '96 that I don't understand,
  in which case I'd be grateful if you'd explain to me where I've gone
  wrong.  As far as I understand, the compiler is complaining about
    type 'f field_binding'    = 'f * Exp.intexp
  not maching its definitional specification, even though the
  definitional specification appears identical...
 [dbm]
  Yes, definitely a bug.  The bug goes away if the call of G is expanded
  inline, and also if the substructure A is eliminated and t is defined
  in terms of a constant type (e.g. type t = int).
 [Zhong, 2/25/97]
  Norman's program is caused by a problem in Instantiation, more
  specifically,

    modules/instantiate.sml
      When instantiating DEFtyc and GENtyc, the old code does not create
      a new stamp, this is wrong because the tycon in signature would then
      have the same tycId as its instantiation tycon. This makes two different
      tycons map to the same binding in the modmaps, causing a bunch of 
      mysterious bugs.

  I'll send the fix to be included into 109.25.1. 

Fix:
Test: bug1155.sml
Owner: dbm, Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1156
Title: subscript raised for intmap entry that exists
Keywords: 
Submitter: Lal George
Date: 2/13/97
Version: 109.25 (bug not 109.23)
System: sgi-irix5.3
Severity: major
Problem: subscript raised for intmap entry that exists
Code: (bug1156.sml)
  (** Just the regular Intmap module pulled out of the compiler. **)

  structure I :
    sig
      type 'a intmap
      val new : unit -> bool intmap
      val add : '2a intmap -> int * '2a -> unit
      val map : 'a intmap -> int -> 'a
    end =
  struct
    open Array List
    infix 9 sub
    datatype 'a bucket = NIL | B of (int * 'a * 'a bucket)
    datatype 'a intmap =
      H of {table: 'a bucket array ref,exn: exn}
    val new = fn () => H{table=ref(array(16,NIL)),exn=Overflow}
    fun index () = 
      let val k = 16 (* Array.length a *)
	  val v = Word.fromInt(k - 1)
	  val w = Word.andb(0wx2, v) 
	  val z = Word.toInt w
       in z
      end
    fun map (H{table,exn}) =
	(fn i => let val ref a = table
		     val nn = index () 
		     val _ = print ((Int.toString nn) ^ " nnn \n")
		     fun find NIL = raise exn
		       | find(B(i',j,r)) = if i=i' then j else find r
		 in find(a sub nn) 
		 end)

    fun add _ _ = ()
  end;

  val x = I.map (I.new())  2;

Transcript:
  Running it in the current compiler shows that nn is assigned a wrong
  value. 

  use "bug1156.sml";
  [opening bug1156.sml]
  structure I :
    sig
      datatype 'a intmap ... (hidden constructors)
      val new : unit -> bool intmap
      val add : 'a intmap -> int * 'a -> unit
      val map : 'a intmap -> int -> 'a
    end
  ~1073741822 nnn 

  uncaught exception subscript out of bounds 
    raised at: zintmap.sml:31.16-31.19
  - 

Comments:
 [Zhong]
  I can't simplify the code furthermore. My guess is that it 
  is caused by the same bug you and Lorenz have identified
  a few days ago, because:

  (1) If I change "val z = Word.toInt w" to "val z = Word.toIntX w"
      the bug goes away.

  (2) If I turn off cpsopt, the bug goes away. The bug seems to only
      occur for a particular sequence of word manipulation instructions
      (mostly likely caused by the same "move-with-same-src-and-tgt" problem)

 [Lal]
  Yes. You are right.

  I ran the same test case in my version of 109.25 that contained that
  bug fix, and it worked fine. Thanks.

Fix:
Test: bug1156.sml
Owner: Lal
Status: fixed in 109.25.1 (Lal)
----------------------------------------------------------------------
Number: 1157
Title: div and quot give incorrect answers
Keywords: div, quot
Submitter: Perry Cheng <Perry_Cheng@inbox.fox.cs.cmu.edu>
Date: 2/13/97
Version: 109.19, 109.23, 109.25
System: alpha-osf1(2.0)
Severity: major
Problem: 
  div and quot give incorrect answers
Transcript:
  - 7 div ~4;
  val it = ~3 : int
  - Int.quot(7,~4);
  val it = ~2 : int

 also (from Andrew Kennedy)
  - ~10 div 10000;
  val it = ~2 : int

Comments:
  The answers should be ~2 and ~1, respectively.
Fix:
  There is a bug in cps/contract.sml. 
  The one line diff below should be applied, if you are familiar with
  recompiling the compiler; otherwise the fix will be in 109.25.1.
  ----------------------------------------------------------------------

  diff -c -r1.2 contract.sml
  *** 1.2 1997/02/08 00:09:31
  --- contract.sml        1997/02/14 16:27:19
  ***************
  *** 959,965 ****
	 | (P.arith{oper=P./,...}, [v, INT 1]) => (click "K"; v)
	 | (P.arith{oper=P./,...}, [INT i, INT 0]) => raise ConstFold
	 | (P.arith{oper=P./,kind=P.INT 31}, [INT i, INT j]) =>
  !               let val x = i div j in x+x; click "L"; INT x end
	 | (P.arith{oper=P.+,...}, [INT 0, v]) => (click "M"; v)
	 | (P.arith{oper=P.+,...}, [v, INT 0]) => (click "N"; v)
	 | (P.arith{oper=P.+,kind=P.INT 31}, [INT i, INT j]) =>
  --- 959,965 ----
	 | (P.arith{oper=P./,...}, [v, INT 1]) => (click "K"; v)
	 | (P.arith{oper=P./,...}, [INT i, INT 0]) => raise ConstFold
	 | (P.arith{oper=P./,kind=P.INT 31}, [INT i, INT j]) =>
  !               let val x = Int.quot(i, j) in x+x; click "L"; INT x end
	 | (P.arith{oper=P.+,...}, [INT 0, v]) => (click "M"; v)
	 | (P.arith{oper=P.+,...}, [v, INT 0]) => (click "N"; v)
	 | (P.arith{oper=P.+,kind=P.INT 31}, [INT i, INT j]) =>

Test: bug1157.sml
Owner: Lal
Status: fixed in 109.25.1
----------------------------------------------------------------------
Number: 1158
Title: datatype representation incorrect
Keywords: datatypes, representation analysis
Submitter: Kenneth Cline <Kenneth_Cline@silver.fox.cs.cmu.edu>
Date: 2/16/97
Version: 109.25
System: -
Severity: major 
Problem: 
  The program included below produces the wrong answer when compiled in
  smlnj 109.25.  Instead of evaluating to 1, val should_be_one ends up
  as a number which is almost certainly a memory address.

  When compiling this program, version 109 produces the error message:

    abug.sml:30.16-30.31 Error: The constructor S of datatype session
    has different representations in the signature and the structure.  
    Change the definition of the types carried by the constructors in the
    functor formal parameter and the functor actual parameter so that
    they are both abstract, or so that neither is abstract.

  This is a serious bug for us because the Fox Net has a lot of
  datatypes which include word32s in structures which become actual
  parameters to functors.  In case this is a difficult bug to fix, is it
  possible to get the old error message back?

Code:
  signature PROTOBUG =
  sig
    type address
    datatype session = S of address -> int
    val session: session
  end

  structure Arg =
  struct
    structure Lower =
      struct
	type address = Word32.word
	datatype session = S of address -> int
	val session = S (fn a => Word32.toInt a)
      end
     datatype address = A of Word32.word
     fun resolve (A host) = host
  end

  functor Connectbug (structure Lower: PROTOBUG
		      type address
		      val resolve: address -> Lower.address) =
  struct
    type address = address
    datatype session = S of address -> int
    val session = S (case Lower.session of (Lower.S lower_connect) =>
		       (fn address => lower_connect (resolve address)))
  end

  structure AA = Connectbug (Arg)

  val should_be_one = case AA.session of AA.S connect => connect (Arg.A 0w1)


Transcript:
  - use "bug1158.sml";
  [opening bug1158.sml]
  ...
  val should_be_one = 4760456 : int

Comments:
 [Zhong, 2/17/97]
  Thanks for the bug report. The bug is caused by the incorrect
  implementation of one of the wrappers. I have fixed it in my
  version of 109.25+, and I'll incorporate the fix into version 109.25.1.

  Just curious, since pre-109.24 won't accept code like above, did you
  write these code recently ? FoxNet seems to be one of those applications 
  that really require matching concrete datatype reps against abstract
  datatype reps.

Fix:
  translate/wrapping.sml
  translate/ltycomp.sml
  translate/ltyprim.sml
    Fixing the incorrect wrapper bug, BUG 1158, reported by Ken Cline 
    (zcline.sml). This also fixes the core dump bug, BUG 1153,
    reported by Nikolaj. 
Test: bug1158.sml
Owner: Zhong
Status: fixed in 109.25.1 (Zhong, 2/26/97)
----------------------------------------------------------------------
Number: 1159
Title: extraneous types included in pervasive environment
Keywords: environment, pervasivies, Basis
Submitter: John Reppy
Date: 2/17/97
Version: 109.25 
System: -
Severity: major 
Problem: 

  > > > structure Arg =
  > > > struct
  > > >   structure Lower =
  > > >     struct
  > > >       type address = word32
  > > 
  > > word32 == Word32.word???
  > 
  > Yes.  Type Word32.word is defined as word32 in boot/word32.sml.

  It seems that certain internal types (word8, word32, int32) are leaking
  out into the pervasive environment.  This is cased by the "open PrimTypes"
  in boot/bind-toplevel.sml.  We should replace it with rebindings of the
  top-level types.

Code:           
    val x : word8 = 0w8;

Transcript:
    - val x : word8 = 0w8;
    val x = 0wx8 : word8
    -
Comments:
    The infrastructure to fix this already exists in bind-toplevel.sml.
    The bug is caused by PrimTypes being opened.

Fix:
    Once we can say:
	datatype 'a ref = datatype PrimTypes.ref
   
    the line that opens PrimTypes can be removed.

 [jhr, 8/26/97]
  I did this by replacing the opening of PrimTypes in boot/bind-toplevel.sml
  with

	  datatype ref = PrimTypes.ref

  The special properties of references (equality, etc.) still seem to hold.

Test: bug1159.sml
Owner: dbm, Zhong, Matthias
Status: fixed in 109.31 [jhr]
----------------------------------------------------------------------
Number: 1160
Title: Compiler bug: PPAbsyn: unexpected absyn expression in ppExp'
Keywords: prettyprinting
Submitter: John Reppy
Date: 2/17/97
Version: 109.25
System: -
Severity: major 
Problem: 
  "Compiler bug: PPAbsyn: unexpected absyn expression in ppExp'" generated
  during prettyprinting.
Transcript:
  - val (_, x) = true;
  stdIn:1.1-2.13 Error: pattern and expression in val dec don't agree (tycon mismatch)
    pattern:    'Z * 'Y
    expression: bool
    in declaration:
      (_,x) =
      (case true
	of (_,x) => {1=x})
  stdIn:1.1-2.13 Error: selecting a non-existing field from a record (type mismatch)
    the field name: 1
    the record type:    _
    in expression:Error: Compiler bug: PPAbsyn: unexpected absyn expression in ppExp'
  - 
Comments:
  The compiler bug is fixed, but the form of the declaration printed in
  the error message is very distorted from the user's point of view.  This
  problem is reported in 1183.
Fix:
Test: bug1160.sml
Owner: dbm, Zhong
Status: fixed in 109.27 [dbm]
----------------------------------------------------------------------
Number: 1161
Title: Win32.FileIO.getFileTime' not accessing correct time stamp
Keywords: file access time, Win32
Submitter: Andrew Stevens <Andrew.Stevens@comlab.ox.ac.uk>
Date: 2/17/97
Version: 109.25
System: x86-Win32
Severity: major
Problem: 
  The OS.FileIO.modTime function and the underlying Win32.FileIO.getFileTime' 
  functions appear not to be accessing the correct time-stamp.   The returned 
  timestamp never changes when a file is written to (e.g. by editting and 
  saving).  
Comments:
 [Lorenz]
  Thanks for the report.  The runtime was querying for creation time, 
  not access time; this is fixed for the next version.

Fix:
Test:
Owner: Lorenz
Status: fixed in 109.25.1
----------------------------------------------------------------------
Number: 1162
Title: uncaught exception Io: filePosIn failed on "foo" ...
Keywords: IO, TextIO
Submitter: Stephen Weeks <sweeks+@research.nj.nec.com>
Date: 2/18/97
Version: 109.21
System: ?
Severity: major 
Problem: 
  uncaught exception Io: filePosIn failed on "foo" ...
Transcript:
  Standard ML of New Jersey, Version 109.21, October 28, 1996 [CM; autoload enabled]
  - let val file = "foo"
  >   val ins = TextIO.openIn file
  >   val _ = TextIO.input1 ins
  > in TextIO.setPosIn(ins,TextIO.getPosIn ins) ;
  >   TextIO.closeIn ins
  > end;

  uncaught exception Io: filePosIn failed on "foo" with exception Fail: bogus position
    raised at: boot/NewIO/text-io-fn.sml:132.14-132.56

Comments:
  I ran strace to see what was going on.  Here is the snippet of the
  relevant part of the strace output.

  > open("foo", O_RDONLY)                   = 4
  > fstat(4, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
  > lseek(4, 0, SEEK_CUR)                   = 0
  > read(4, "foo is a nonempty file\n", 4096) = 23
  > lseek(4, 23, SEEK_SET)                  = 23
  > read(4, "", 1)                          = 0
  > getrusage(RUSAGE_SELF, {ru_utime={1, 430000}, ru_stime={0, 390000}, ...}) = 0
  > write(1, "\nuncaught exception Io: filePos"..., 86) = 86
  > write(1, "  raised at: boot/NewIO/text-io-"..., 53) = 53

  The problem is that the position returned by the call to getPosIn is
  wrong - it should be 1, but it appears to be 23 + 1 (as evidenced by
  the second lseek followed by the read).  Looking at the source code
  (boot/NewIO/text-io-fn.sml), it looks like the function extendStream
  on line 139 is broken.  In particular, the basePos for the new buffer
  is wrong, since it is computed *after* the read of the buffer, and
  hence points after the end, rather than at the beginning of the new
  buffer.
Fix:
Test:
Owner: jhr
Status: fixed in 109.25.1
----------------------------------------------------------------------
Number: 1163
Title: Wrong match compiler warning
Keywords: match compiler, redundant match, warning message
Submitter: manuel@cs.berkeley.edu
Date: Feb 20 97
Version: 109.25
System: x86/linux
Severity: low
Problem: Match compiler gives erroneous 'Redundant' warning
Code:
  datatype t = A of int | B of int;

  fun f (a,b) =
      case (a,b)
	of (A i1, (B i2 | A i2)) => i1 + i2
	 | ((A i1 | B i1), A i2) => i1 - i2
	 | (B i1, B i2) => i1 * i2;

Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled]
  - datatype t = A of int | B of int;
  datatype t = A of int | B of int
  - fun f (a,b) =
      case (a,b)
	of (A i1, (B i2 | A i2)) => i1 + i2
	 | ((A i1 | B i1), A i2) => i1 = = = - i2
	 | (B i1, B i2) => i1 * i2;
  = = stdIn:18.5-21.32 Warning: match redundant
	    (A i1,(B i2 | A i2)) => ...
      -->   ((A i1 | B i1),A i2) => ...
	    (B i1,B i2) => ...

  val f = fn : t * t -> int

 [Another example from Perry Cheng, 2/20/97]
  datatype dt = A | B
  - fun f (A,A) = 0
  =   | f (B,B) = 1
  =   | f ((A|B),(A|B)) = 2;
  stdIn:<nullRegion> Warning: match redundant
	    (A,A) => ...
	    (B,B) => ...
      -->   ((A | B),(A | B)) => ...

Comments: The produced code however include the case, since:
  - f (B 1, A 2);
  val it = ~1 : int

Fix:
Test: bug1163.1.sml, bug1163.2.sml
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1164
Title: compiler bug after failure to generalize explicit type var
Keywords: type checking
Submitter: Dave MacQueen
Date: 3/21/97
Version: pre 109.26
System: any
Severity: major
Problem: a compiler bug message is generated in translate phase
  in code where an explicitly typed variable apparently is incorrectly
  generalized at it's binding declaration.
Code:
  fun f x =   (* type metavar tv(x) has depth 1 *)
      let fun g(y: 'a) =  (* 'a is user bound tyvar scoped at g decl; depth 2 *)
	     if true then x else y  (* forces unification of 'a and tv(x)
	                             * which should reset 'a depth to 1 *)
       in 0 
      end;
Transcript:
  - use "test/src/type1.sml";
  [opening test/src/type1.sml]
  Error: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       translate/translate.sml:129.39
	       translate/translate.sml:129.39
	       util/stats.sml:164.40
	       build/evalloop.sml:191.58
	       build/evalloop.sml:273.46-273.49

Comments: 
Fix:
Test: bug1164.sml
Owner: dbm, Zhong
Status: fixed in 109.26 [dbm]
----------------------------------------------------------------------
Number: 1165
Title: wrong type name printed for OS.Process.success
Keywords: printing, types
Submitter: Dave MacQueen
Date: 3/21/97
Version: 109.25.2
System: -
Severity: minor 
Problem: 
  The top level prints the type of OS.Process.success as "?.OS_Process.status"
Code:
Transcript:
  - OS.Process.success;
  val it = 0 : ?.OS_Process.status
  - 
Comments:
Fix:
Test: bug1165.sml
Owner: jhr, dbm
Status: open
----------------------------------------------------------------------
Number: 1166
Title: where type causes Compiler bug: TypesUtil: tycStamp PATHtyc u
Keywords: where types, signatures, modules
Submitter: Zhong Shao
Date: 3/23/97
Version: 109.25.2
System: -
Severity: major
Problem: 
  where type causes Compiler bug: TypesUtil: tycStamp PATHtyc u 
Code: 
  functor F(type u) = 
  struct
     abstraction A : sig type t end where type t = u =
      struct
	 type t=u
      end
  end
Transcript:
  - use "bug1166.sml";
  [opening bug1166.sml]
  Error: Compiler bug: TypesUtil: tycStamp PATHtyc u

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:164.40
	       elaborate/elabmod.sml:993.8
	       elaborate/elabmod.sml:1209.7
	       elaborate/elabmod.sml:1097.33
	       util/stats.sml:164.40
	       build/evalloop.sml:120.38
	       build/evalloop.sml:191.58
	       build/evalloop.sml:273.46-273.49

Comments:
Fix: change definition of ModuleUtil.descToTyc for the EXTCONSTtyc case
  to interpret within DEFtyc bodies.
Test: bug1166.sml
Owner: dbm
Status: fixed in 109.26 [dbm, 3/24/97]
----------------------------------------------------------------------
Number: 1167
Title: Compiler bug: boxity
Keywords: printing, representation
Submitter: Norman Ramsey <nr@cs.virginia.edu>
Date: 3/2/97
Version: 109.23 and 109.25
System: linux
Severity: minor
Problem: 
  compiler raises Boxity while loading a file.
Code: bug1167.sml (original), bug1167.2.sml (reduced)
Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled]
  - use "bugs/bug1167.2.sml";
  [opening bugs/bug1167.2.sml]
  datatype exp = UNARY of (string * int) * int
  val deco =
    ("\^F\128\000\^F\182 q<\216\^C\160d\158\^P\000\^A\129\195\000\000\154\^P \127\218\^F\160\^D\150\^P \130\214!\160\000\240!\160\^H\218!\160\^D\176\^A\160\^D\140\^A\160\^L\129\198@\000\128\161\128\^D\000\000\000\000\000\000\000\000\000\000#",
  uncaught exception Boxity
    raised at: boot/system.sml:98.27-98.33
	       print/ppobj.sml:356.20
	       print/ppobj.sml:356.20
	       print/ppobj.sml:356.20
	       print/ppobj.sml:356.20
	       util/pp.sml:545.6
	       build/evalloop.sml:191.58
	       build/evalloop.sml:283.46-283.49
Comments:
Fix:
Test: bug1167.sml, bug1167.2.sml
Owner: Zhong
Status: fixed in 109.25.2 [Zhong]
----------------------------------------------------------------------
Number: 1168
Title:       Interrupt within a 'use'
Keywords:    
Submitter:   riccardo@research.att.com
Date:        03/04/1997
Version:     109.25
System:	     checked on x86 (Solaris 2.5.1), IRIX 5.0.
Severity:    minor
Problem:     Interrupts during the execution of 'use' produce a 
             TopLevelCallcc exception (problem also occurs with
             useStream).
Code:	     Given a file 'bug.sml' containing:
                 fun inf () = inf (): unit;
                 inf ();
Transcript:  Given the file 'bug.sml' as above, and interrupting it via
             a control-C produces:
   - use "bug.sml";
   [opening bug.sml]
   val inf = fn : unit -> unit
   ^C 
   uncaught exception in compiler: exception TopLevelCallcc
     raised at: build/compile.sml:330.30-330.44
                util/stats.sml:168.40
                build/evalloop.sml:190.58
Comments:
  The bug seems to be present in 109.23 as well.
 [jhr, 4/3/97]
  This is a bug in the top-level loop code.
Test: *
Owner: 
Status: open
----------------------------------------------------------------------
Number: 1169
Title: problems printing polymorphic records
Keywords: printing, representation
Submitter: Stephen Weeks <research.nj.nec.com!sweeks+> 
Date: 3/8/97
Version: 109.25.2
System: -
Severity: major 
Problem: printing a pair containing a polymorphic function produces
  Boxity or Subscript exception, depending on type of other component.
Code:
Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled]
  - (1,fn _ => 13);
  GC #0.0.0.0.4.167:   (10 ms)

  uncaught exception in compiler: exception Boxity
    raised at: boot/system.sml:115.27-115.33
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       util/pp.sml:545.6
	       build/evalloop.sml:190.58
  - ("",fn _ => 13) ;

  uncaught exception in compiler: subscript out of bounds
    raised at: print/ppobj.sml:472.20-472.25
	       print/ppobj.sml:344.20
	       print/ppobj.sml:344.20
	       util/pp.sml:545.6
	       build/evalloop.sml:190.58
  - 
Comments:
 [Zhong, 3/24/97]
  Printing polymorphic records is still not correct. For example,
      val x = (3, fn _ => 4) would cause boxity errors in ppobj. 
  Fully supporting this requires major changes in ppobj, so I temporarily
  turned off the pretty-printing for polymorphic records
 [Zhong, 4/9/97]
  Temporary hack prints "polymorphic record" as a stand-in.  True
  fix requires extensive rewrite of PPVal.
Fix:
Test: bug1169.1.sml, bug1169.2.sml
Owner: Zhong
Status: open
----------------------------------------------------------------------
Number: 1170
Title: where type problem
Keywords: where type
Submitter: Frank Pfenning <cs.cmu.edu!fp+>
Date: 3/13/97
Version: 109.25.2
System: -
Severity: major 
Problem: 
  1. The parser does not seem to like
       <signature> where type t1 = <type1> and t2 = <type2>
     which should be part of the SML'96 syntax, I believe

  2. When I replace this by
     <signature> where type t1 = <type1>
		 where type t2 = <type2>

  I get the error

  Error: Compiler bug: TypesUtil: tycStamp PATHtyc parse_result

  uncaught exception exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       util/stats.sml:164.40
	       elaborate/elabmod.sml:1097.33
	       util/stats.sml:164.40
	       sched/recompile.sml:228.38-228.41

Comments: [dbm, 3/23/97] 
  The syntax in 1 is legal SML (according to Figure 19, p. 59 of the
  Revised Defn. 

  The syntax in 2. should work, and does in simple examples I've
  tried (bug1170.2.sml).  I haven't been able to reproduce this behavior.

Fix: changed ml.grm, at the cost of adding a 2nd shift-reduce conflict!
Test: bug1170.1.sml, bug1170.2.sml
Owner: dbm
Status: fixed in 109.27 [dbm, 4/10/97]
----------------------------------------------------------------------
Number: 1171
Title: where type on opaque functor result signature
Keywords: modules, functors
Submitter: George Russell <persimmon.co.uk!george> 
Date: 3/17/97
Version: 109.26-
System: -
Severity: major 
Problem: where type clause on opaque functor result signature doesn't
 work.
Code:
  functor WRef(type u):>sig
     type t
     type href
     val new:t->href
  end where type t=u =
  struct
     type t=u
     type href=u ref
     fun new x=ref x
  end

  structure WR=WRef(type u=int)
  val h=WR.new 0
Transcript:
  - use "bugs/bug1171.sml";
  [opening bugs/bug1171.sml]
  bugs/bug1171.sml:15.1-15.15 Error: operator and operand don't agree [literal]
    operator domain: u
    operand:         int
    in expression:
      WR.new (0 : int)

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:191.58
	       build/evalloop.sml:283.46-283.49
  - 
Comments:
  This was fixed as a side-effect of fixing 1166.
Fix: same as for 1166.
Test: bug1171.sml
Owner: dbm
Status: fixed in 109.26 [dbm,3/24/97]
----------------------------------------------------------------------
Number: 1172
Title: error message about non-constructor in pattern needs more info
Keywords: error messages, patterns, constructors
Submitter: Allen Stoughton <cis.ksu.edu!allen> 
Date: 3/20/97
Version: 109.25
System: -
Severity: minor 
Problem: 
The following 109.25 error message doesn't indicate the identity of
the offending non-constructor (::#).

Transcript:
  Standard ML of New Jersey, Version 109.25, February 1, 1997
  - fun f (#"a"::#"b"::_) = true;
  stdIn:7.5-7.29 Error: non-constructor applied to argument in pattern
Comments:
Fix:
Test: bug1172.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1173
Title:		Abstraction-type-export-inconsistency
Keywords:	"abstraction", "ints", "types"
Submitter:	Thomas R. Schmidt, schmidts@tagetes.informatik.uni-stuttgart.de
Date:		21/03/97
Version:	109.25
System:		Linux 1.2.13
Severity:	minor
Problem:	Types in abstractions are not always exported, so it is not
		possible to give a value to a function, e.g.
Code:
(* Author : Thomas Schmidt (schmidts@tagetes.informatik.uni-stuttgart.de)
 * Date   : 18.03.97, 21.03.97
 * System : Linux 1.2.13
 * Version: 1.09.21.1 and 1.09.25
 * File   : sml-bugtest.sml
 * Use for: Test the presence of the bug that prevents types to be
 *          exported from abstractions.
 *)

(* First a little preparation *)
signature S =
    sig
        type t
    end

structure R: S =
    struct
        type t = real
    end

structure I: S =
    struct
        type t = int
    end

(* The abstraction/open combination can be replaced by the :> - Operator in
 * 1.09.25+. Doesn't change the behaviour, though:
 *)
(*
functor F(T:S) :>
    sig type t = T.t
        val one: T.t -> T.t
        val two: t -> t
    end =
struct
    type t = T.t
    fun one t = t
    fun two t = t
end
*)

functor F(T:S) =
    struct
        abstraction dummy:
            sig type t = T.t
                val one: T.t -> T.t
                val two: t -> t
            end
        = struct
            type t = T.t
            fun one t = t
            fun two t = t
          end

        open dummy
    end

structure FI = F(I);
structure FR = F(R);

(* This is executed in 109.21.1 without problems.
 * The Problem lies here with .25. Sometimes it works, sometimes it doesn't.
 *)

(* works under .25 *)
FI.one 2;
FR.one 2.0;
FR.two 2.0;

(* This doesn't work under .25 *)
FI.two 2;

Transcript:	
(* Stuff deleted *)
val it = 2 : I.t
val it = 2.0 : R.t
val it = 2.0 : ?.t
Error: Compiler bug: Unify: unexpected tycon in tycon_eqprop

uncaught exception exception Error
  raised at: util/errormsg.sml:51.14-51.19
             typing/typecheck.sml:391.9
             util/stats.sml:168.40
             elaborate/elabmod.sml:1272.47
             elaborate/elabmod.sml:1277.4
             util/stats.sml:168.40
             build/evalloop.sml:119.38
             build/evalloop.sml:190.58
             build/evalloop.sml:272.46-272.49

Comments:	Obviously, you can work around the bug. If someone told me
		that earlier!-))
Fix:
Test: bug1173.sml
Owner: dbm
Status: fixed in 109.26
----------------------------------------------------------------------
Number: 1174
Title: Compiler bug: SigMatch:packElems: STRspec (secondary error)
Keywords: secondary error, modules
Submitter: Robert Findler <cs.rice.edu!robby>
Date: 3/26/97
Version: 109.26
System: -
Severity: minor 
Problem: 
  After a signature match error, "Compiler bug: SigMatch:packElems: STRspec".
Code:
   signature sig1 =
       sig 
	   type t 
	   val f : int -> t
       end

   functor fun1() :> sig1 = 
       struct 
	   type t = bool

	   fun f(0) = false
	     | f(n) = true
       end

   signature sig2 = 
       sig 
	   structure str1 : sig1
	   type t 
	   val h : t -> int
       end

   functor fun2(structure str1 : sig1) :> sig2 = 
       struct
	   structure st1 = str1
	   type t = str1.t
	   fun h(false) = 0
       end
Transcript:
   stdIn:34.9-39.8 Error: unmatched structure specification: str1
   stdIn:34.9-39.8 Error: value type in structure doesn't match signature spec
       name: h
     spec:   ?.t -> int
     actual: bool -> int
   Error: Compiler bug: SigMatch:packElems: STRspec

Comments:
Fix: added case tests to str and fct branches of packElems.
Test: bug1174.sml, bug1174.1.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/30/97]
----------------------------------------------------------------------
Number: 1175
Title:       uncaught exception RegMap
Keywords:    core
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        3/27/97
Version:     109.26
System:      Alpha
Severity:    Major
Problem:     "uncaught exception RegMap" upon reading file
Code:        
(*----------------------------------------------------------------------*)
(* A very general datatype for state monads				*)
(*----------------------------------------------------------------------*)
datatype ('s, 'r) Monad = St of 's -> 'r * 's
  
(*----------------------------------------------------------------------*)
(* Wadler's unit and bind for state monads				*)
(*----------------------------------------------------------------------*)
fun unit v = St (fn state => (v, state))
fun bind (St st) f =
  St (fn s => let val (v, s') = st s in 
              let val St st' = f v 
              in st' s' end end)

(*----------------------------------------------------------------------*)
(* Map with state							*)
(*----------------------------------------------------------------------*)
fun monadmap f [] = 
    unit []

  | monadmap f (x::xs) =   
    bind (f x) (fn y =>
    bind (monadmap f xs) (fn ys =>
    unit (y::ys)))


Transcript:
[opening test]

uncaught exception RegMap
  raised at: util/intmap.sml:28.41-28.44
             util/stats.sml:164.40
             util/stats.sml:164.40
             build/evalloop.sml:191.58
             build/evalloop.sml:283.46-283.49

Comments: 
  not quite repeatable -- sometimes get "uncaught exception
  in compiler: subscript out of bounds"
 [Lal, 3/26/97]
  The program below has no floating point but generates :

  v764(v996[PV],v995[PV],v994[C],v993[PV],v992[PV],v991[PV],v990[PV]) =
     {(I)0,v990} -> v601
     v995.1 -> v997[I]
     if i31=(v997,(I)6) [v603] then
	funwrap((I)0) -> v604[R]
	funwrap(v990) -> v605[R]
	{RK_FBLOCK 2,v604,v605} -> v606
	v994(v994,v993,v992,v991,v606)
     else
	v994(v994,v993,v992,v991,v601)

  What's even more weird is that it is trying to unwrap the integer
  constant zero into a floating point value:

	funwrap((I)0) -> v604[R]

 [dbm, 3/26/97]
  Works in 109.25 (on sparc-solaris), but fails in 109.25.1, so probably
  do to a diff between 109.25 and 109.25.1.  Likely candidates are 
  cps or translate.
 [Zhong, 3/26/97
  These are actually dead code. Representation analysis insert wrappers 
  (using typecase) in the front end; the CPS optimizer is not good enough
  to eliminate these dead code, but it does do some partial constant 
  propagations. This leads to strange code such as 

	funwrap ((I) 0) -> v604[R]

  And I am sure the code generator will complain, thus the bug. 
      > 
      > uncaught exception RegMap

  This kind of scenerio happens before, I think we still allow
  CPS code such as SELECT((I) 0, 0).  

 [dbm, 4/18/95]
  In 109.27, behavior changes slightly but bug is still present:

    - use "tests/bug1175.sml";
    [opening tests/bug1175.sml]

    uncaught exception FPRegEA
      raised at: cps/generic.sml:98.67-98.74
		 util/stats.sml:164.40
		 util/stats.sml:164.40
		 build/evalloop.sml:191.58
		 build/evalloop.sml:283.46-283.49

Fix:
Test: bug1175.sml
Owner: Zhong
Status: fixed in 109.28 [Zhong, 4/30/97]
----------------------------------------------------------------------
Number: 1176
Title: compiler bug printing type in error message
Keywords: printing, types
Submitter: Lorenz Huelsbergen
Date: 3/26/97
Version: 109.26
System: -
Severity: major
Problem: While printing a type in an error message the message
 "Compiler bug: PPType: printTyvar" occurs.
Transcript:
  - : canna.research.bell-labs.com 192; /usr/local/sml/109.26/bin/sml-cm
  Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
  - fun normalize s x = (x/s);
  stdIn:17.23 Error: overloaded variable not defined at type
    symbol: /
    type: Error: Compiler bug: PPType: printTyvar
  -
Comments:
Fix: fill in missing cases in PPType.tyvarPrintname
Test: bug1176.sml
Owner: dbm
Status: fixed in 109.27 [dbm, 3/27/97]
----------------------------------------------------------------------
Number: 1177
Title: inappropriate nongeneralizable type variable error
Keywords: type checking, polymorphism, value restriction
Submitter: John Reppy
Date: 3/27/97
Version: 109.26
System: -
Severity: major 
Problem: A type variable that should be generalized is not, resulting
  in an error message.
Code: (* bug1177.sml *)
  val z =
      let val tbl = ref nil
	  fun ins x = tbl := x :: !tbl
       in ins 1
      end;

Transcript: (with Compiler.Control.internals := true *)
  - use "bug1177.sml";
  [opening bug1177.sml]
  bug1177.sml:4.9-4.26 Warning: value restriction prevents type  variable generalization : 'Z.M[10000000]
  bug1177.sml:5.2-5.30 Error: nongeneralizable type variable
    ins : 'Y.M[0] -> unit[D;unit]

  uncaught exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:191.58
	       build/evalloop.sml:283.46-283.49
Comments:
Fix:
Test: bug1177.sml
Owner: dbm
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 1178
Title:       Overloaded constants in patterns
Keywords:    Patterns, constants, type constraints, overloading
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        3/27/97
Version:     109.26
System:      Alpha
Severity:    Minor
Problem:     Compiler bug rather than literal range error
Code:        fn 0w1000 : Word8.word => "a"
Transcript:  Error: Compiler bug: MatchComp: overflow in pattern
Fix:
Test: bug1178.sml
Owner: jhr
Status: fixed in 109.27 [dbm, 4/11/97]
----------------------------------------------------------------------
Number: 1179
Title: unmatched type specification leads to a Compiler bug error
Keywords: 
Submitter:      Elsa L. Gunter
Date:           27 March 1997
Version:        109.26
System:         linux, version 2.0
Severity:       minor
Problem: 
  An unmatched type specification leads to a Compiler bug error.
Code:
  structure A : sig type 'a t val f : 'a -> 'a t end = struct fun f y = [y] end;

Transcript:
  canna% sml
  Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
  - use "type_bug.sml";
  [opening type_bug.sml]
  type_bug.sml:11.1-11.78 Error: unmatched type specification: t
  Error: Compiler bug: TypesUtil: tyvarType 124

  uncaught exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       modules/sigmatch.sml:703.39
	       modules/sigmatch.sml:743.30
	       modules/sigmatch.sml:813.24
	       elaborate/elabmod.sml:1008.8
	       ...
Comments:
 [dbm, 3/27/97] Similar to bug 1174.
Fix: made TypesUtil.tyvarType do something sensible with WILDCARDty argument.
Test: bug1179.sml
Owner: dbm, Zhong
Status: fixed in 109.28 [dbm, 4/20/97]
----------------------------------------------------------------------
Number: 1180
Title: bug in blastRead, blastWrite?
Keywords: blastRead, blastWrite
Submitter: Chris Paris <cap@cmu.edu>
Date: 3/20/97
Version: 109.25.2, 109.23, 109.19
System: ?
Severity: major 
Problem: 
  I've been using the SML/NJ blast read and write primitives to store
  and retrieve a complex data structure in a program I'm working
  on. This technique has been working fine for over a year. Recently,
  the program has been breaking in strange ways, and I wonder if perhaps
  the blast read/write primitives have not kept up with the other work
  on the compiler. I've not yet been successful in coming up with a
  short example program that demonstrates that the problem is with an
  SML/NJ primitive, but I thought I'd ask at this point, in case you
  know for sure that there's a problem. I've been having these problems
  with 109.25.2, 109.23, and 109.19. The problem exhibits itself
  slightly differently in each of those versions.

  I'm curious about whether anyone else is using the blast read/write
  primitives in their work, and also I'd like to know why these
  facilities were devised in the first place. Was it for a specific
  project?

Code:
Transcript:
Comments:
 [jhr, 3/25/97]
  As far as I know, there is no reason that blast read/write should
  be broken, but it is possible.  What version did it last work in?
  One way to test this would be to blast in a value after you blast it
  out, and make sure it hasn't changed.

 [Chris Paris, 3/25/97]
  To provide a little context here, our application is a single server
  application that provides UNIX system administration functionality for
  all of the machines in CMU SCS. There is a single SML process on one
  machine, which accepts connections from clients on the network.
  That's a vast oversimplification (makes it sound like a bunch of perl
  scripts), but at least it indicates what I'm working on. The size of
  the SML part of the project is a bit over 13,000 lines.

  We've been running our "production version" code on 109.19 for quite a
  while, and it has "seemed" to work. There is the occasional crash or
  weird behavior, which I've previously attributed to possible bugs in
  our SML code, or other bugs in the compiler or runtime system.  Our
  newer code is bigger and more complex, and it fails readily on 109.19
  and anything after that (it fails in a different way with each version
  of the compiler). (And no, I'm not trying to blastRead an object
  written with a different compiler.)

  I'm using blast read/write to store a sort of database. It gets read
  into memory, just once, at startup time, and periodically written out
  in a single blast operation. If the write/read pair were to
  dramatically corrupt the data, then I should expect the overall system
  to fail rather quickly. But if only a few things are messed up, it's
  conceivable that the system would give the impression that everything
  is okay, at least for a time. That's somewhat hard for me to believe,
  but the evidence suggests that that's what's happening.

  I can initialize my "database" from scratch by running some scripts,
  rather than by loading a previously blasted SML runtime value. For a
  few days now I've been running a system that is fully functional
  except that it does no blast read/write operations. We've been unable
  to make this one crash.

  The trouble is, any small test I've performed with the blast
  functions, such as writing out a simpler data structure that I can
  easily verify after reading it back, indicates that the blast
  functions are working fine. Until I can come up with a clear sample
  that causes the blast functions to fail, the best I can say is that
  our whole program appears to work if we don't use it and fails in
  subtle ways if we do use it.

  The obvious risk with using the blast functions is a type mismatch
  between the reading and the writing side, since it's completely up to
  the programmer to get it right. But I think if I were getting the
  types wrong, it would fail immediately. Besides, I have the code
  structured to avoid that possibility. E.g.,

  type db = ...
  fun read_it () : db = ... blastRead ...
  fun write_it (obj : db) = ... blastWrite ...

Fix:
Test:
Owner: jhr
Status: open
----------------------------------------------------------------------
Number: 1181
Title: tmp argument naming in front end
Keywords: absyn
Submitter: Manual Fahndrich <manuel@cs.berkeley.edu>
Date: March 29/97
Version: 109.26
System: x86/Unix
Severity: low
Problem: The function FUNdec in elabutil.sml introduces new temporary
         names for function arguments. Unfortunately, all arguments
	 are called the same, namely "arg". This makes it
	 extremely inconvenient to use the frontend for other compiler
	 work, since the lexical structure is not preserved by the
	 nameing.
Code:
Parse the function:

- fun h x = h x

You get:

val g =
      let val g =
                (fn arg =>
                      (fn arg =>
                            (case (arg,arg)
                              of (h,x) => h (x))))
       in g
      end

Printed using ppDec. The 2nd "arg" shadows the first, if one goes by
identifier names.

Transcript:
Comments:
Fix:
 Use numbered names. arg1, arg2, ....

Test:
Owner: dbm, Zhong
Status: open
----------------------------------------------------------------------
Number: 1182
Title: Error: Compiler bug: PPType: printTyvar
Keywords: types, printing
Submitter:	Lal George
Date:		97/3/31
Version:	109.26
System:		all
Severity:	minor
Problem:	
Code:
	datatype t = INT of int
	fun f (INT n) = INT ~n

Transcript:
    - datatype t = INT of int  fun f (INT n) = INT ~n;
    stdIn:18.17-18.23 Error: operator and operand don't agree [tycon mismatch]
      operator domain: int
      operand:         Error: Compiler bug: PPType: printTyvar

Comments:
Fix:
Test: bug1182.sml
Owner: dbm
Status: fixed in 109.27 [dbm]
----------------------------------------------------------------------
Number: 1183
Title: distorted abstract syntax printed in type error message
Keywords: error messages, printing, abstract syntax
Submitter: Dave MacQueen
Date: 4/1/97
Version: 109.27
System: -
Severity: major 
Problem: distorted abstract syntax printed in type error message
Transcript:
  - val (_, x) = true;
  stdIn:9.1-9.18 Error: pattern and expression in val dec don't agree [tycon mismatch]
    pattern:    'Z * 'Y
    expression:    bool
    in declaration:
      (_,x) =
	(case true
	  of (_,x) => {1=x})

Comments: Derived from 1160.
Fix:
Test: bug1160.sml
Owner: Zhong, dbm
Status: open
----------------------------------------------------------------------
Number: 1184
Title:       Compiler infinite loop
Keywords:    <optional - e.g. "modules", "types", "IO", "reals">
Submitter:   Dino Oliva  oliva@cse.ogi.edu
Date:        04/02/97
Version:     109.26
System:	     sparc-unix
Severity:    major
Problem:     When compiling this code, the compiler seems to go into an
	     infinite loop and eventually runs out of heap and dies.  I
             suspect it is the code generator because it compiles fine on the
             x86-unix platform. 
Code:	     attached below
Transcript:
  [42] sml
  Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled]
  - use "foo.sml";
  [opening foo.sml]
  GC #0.0.0.0.1.3:   (20 ms)
  foo.sml:139.3-139.79 Warning: value restriction prevents type  variable generalization : 'Z
  foo.sml:139.3-139.79 Warning: value restriction prevents type  variable generalization : 'Y
  foo.sml:163.3-163.82 Warning: value restriction prevents type  variable generalization : 'X
  foo.sml:163.3-163.82 Warning: value restriction prevents type  variable generalization : 'W
  foo.sml:202.9-203.47 Warning: value restriction prevents type  variable generalization : 'V
  foo.sml:237.9-237.61 Warning: value restriction prevents type  variable generalization : 'U
  foo.sml:237.9-237.61 Warning: value restriction prevents type  variable generalization : 'T
  foo.sml:237.9-237.61 Warning: value restriction prevents type  variable generalization : 'S
  foo.sml:238.9-238.60 Warning: value restriction prevents type  variable generalization : 'R
  foo.sml:240.9-240.69 Warning: value restriction prevents type  variable generalization : 'Q
  foo.sml:240.9-240.69 Warning: value restriction prevents type  variable generalization : 'P
  foo.sml:241.9-241.54 Warning: value restriction prevents type  variable generalization : 'O
  GC #0.0.0.0.2.41:   (100 ms)
  ... [lots of gc's] ...
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 97124352 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size
  GC #10.141.142.144.150.3024:   (21570 ms)
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284360704 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size
  GC #11.142.143.145.151.3044:   (21550 ms)
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284557312 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size
  GC #12.143.144.146.152.3064:   (21630 ms)
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284753920 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size
  GC #13.144.145.147.153.3084:   (22140 ms)
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284950528 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 86441984 bytes, errno = 12
  /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Fatal error -- unable to allocate minimum size

  [43] 

Comments:
  I've cut down the problem from a couple thousand lines of code
  across several modules to the 250 lines here. Taking out much
  more makes the problem go away. 

  In the MilC structure, changing either the definition of eqmember
  or map2 to the (trivial) commented out versions is sufficient to
  get the compiler to terminate. Unfortunately, these definitions
  are not quite what I need.
 [Zhong, 4/3/97]
  Somehow the closure phase is generating this 16-arguments function
  (which goes beyond the register limits, thus the infinite loop).
Fix:
Test: bug1184.sml
Owner: Zhong
Status: fixed in 109.27 [Zhong]
----------------------------------------------------------------------
Number: 1185
Title: Compiler bug of DECON on data constructors
Keywords: datatypes, dataconstructors
Submitter:      Zhong Shao (shao@cs.yale.edu)
Date:           April 4, 1997
Version:        109.26
System:         sparc
Severity:       medium
Problem:        Compiler bug of DECON on data constructors
Code:           
  structure A = 
  struct

  datatype context 
    = NoContext
    | Local of unit

  fun pp_context (Local a1) = ()
    | pp_context _ = ()

  end      

Transcript:    

daffy% xrun sml.sparc
Standard ML of New Jersey, Version 109.26, March 25, 1997 [new runtime]
- use "zbug.sml";
[opening zbug.sml]
Error: Compiler bug: Wrapping: DECON on a constant or exnconst data constructor

uncaught exception Error
  raised at: util/errormsg.sml:51.14-51.19
             util/stats.sml:164.40
             util/stats.sml:164.40
             util/stats.sml:164.40
             build/evalloop.sml:191.58
             build/evalloop.sml:283.46-283.49
- 

Comments:      unit-carrying data constructors are mis-treated
               as constant constructors.
               

Fix:
Test: bug1185.sml
Owner: Zhong
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 1186
Title: type printing in multi-declaration
Keywords: types, printing
Submitter: Dave MacQueen
Date: 4/7/97
Version: 109.26.1
System: -
Severity: minor
Problem: 
  If a type constructor and a value whose type mentions the type
  constructor are defined in a single top-level declaration, the
  name of the type constructor is printed with "?.".
Code:
  datatype t = A
  val x = A;
Transcript:
  - datatype t = A
    val x = A;
  = datatype t = A
  val x = A : ?.t
  - 
Comments:
Fix:
Test: bug1186.sml
Owner: dbm
Status: open
----------------------------------------------------------------------
Number: 1187
Title: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE
Keywords: translate
Submitter: Lal George
Date: 4/8/97
Version: 109.26.1
System: -
Severity: major
Problem: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE
Code: bug521.sml
Transcript:
  Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled]
  - use "bug521.sml";
  [opening bug521.sml]
  Error: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE

  uncaught exception Error
    raised at: util/errormsg.sml:51.14-51.19
	       translate/translate.sml:129.39
	       translate/translate.sml:129.39
	       util/stats.sml:164.40
	       build/evalloop.sml:191.58
	       build/evalloop.sml:283.46-283.49

Comments: found in regression testing
 [Zhong, 4/8/97]
  This error message is complaining about a type variable that is
  not generalized anywhere. This could be caused by placing the
  wrong value into the "boundtvs" field in the VALdec (VB {...})
  in absyn (during typechecking).

  The code above shows that it might be related to the tyvar of 
  "flex-record", i.e., the type for variable "a" above.

Fix:
Test: bug521.sml
Owner: dbm, Zhong
Status: fixed in 109.27 [dbm, 4/9/97]
----------------------------------------------------------------------
Number: 1188
Title: Compiler bug: Unify: instTyvar 
Keywords: type checking, instTyvar
Submitter: Carlos Puchol (cpg@cs.utexas.edu)
Date: 4/8/97
Version: 109.26.1
System: -
Severity: major 
Problem: Type error causes "Compiler bug: Unify: instTyvar"
Code:
  datatype K = A of int | B of {one:int, two:string};
  val b = B {one = 1, two="TWO"};
  #two b;
Transcript:
  Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [new runtime]
  -  datatype K = A of int | B of {one:int, two:string};
  datatype K = A of int | B of {one:int, two:string}
  -  val b = B {one = 1, two="TWO"};
  val b = B {one=1,two="TWO"} : K
  - #two b;
  Error: Compiler bug: Unify: instTyvar: OPEN/FLEX not instantiated to record type

Comments:
  [Lal, 4/8/97]
  This bug is also exhibited in bug1049. For this test case there used
  to be a fairly nice error message.


  :::::::::::::::::::::::::::::bug1049.sml::::::::::::::::::::::::::
  (* bug1049.sml *)

  fun f x = (map real (#1 x); map op o x);
  ---------------------------bad---------------------------
  val it = () : unit
  Error: Compiler bug: Unify: instTyvar: OPEN/FLEX not instantiated to record type
  ---------------------------outputs-----------------------
  val it = () : unit
  bug1049.sml:3.11-3.40 Error: operator and operand don't agree (type mismatch)
    operator domain: (('Z -> 'Y) * ('X -> 'Z)) list
    operand:         {1:int list, '...W}
    in expression:
      map o x
  bug1049.sml:3.1-3.40 Error: unresolved flex record
  (can't tell what fields there are besides #1)
Fix:
Test: bug1188.sml
Owner: dbm
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 1189
Title: Opening Real crashes system
Keywords: Real, overflow, open
Submitter: Jeff Foster, jfoster@cs.berkeley.edu
Date: 4/9/97
Version: 109.26
System: hpux
Severity: minor
Problem: typing ``open Real;'' at the prompt causes ML to raise an
         exception and makes the system unusable without restarting
Code:    open Real;
Transcript:

Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload
enabled]
- 3+4;
val it = 7 : int
- open Real;
open Real
structure Math :
  MATH
val radix = 2 : int
val precision = 52 : int
val maxFinite = 1.79769313486e308 : real

uncaught exception in compiler: overflow
  raised at: print/ppobj.sml:397.20
             print/ppobj.sml:397.20
             print/ppobj.sml:397.20
             util/pp.sml:545.6
             build/evalloop.sml:191.58
- 3+4;

uncaught exception in compiler: overflow
  raised at: util/stats.sml:164.40
             build/evalloop.sml:120.38
             build/evalloop.sml:191.58


Comments:
Fix:
Test: bug1189.sml
Owner: Lal?
Status: fixed in 109.27 [Lal, 4/11/97]
----------------------------------------------------------------------
Number: 1190
Title:       Exception values matching against exceptions in signatures
Keywords:    Modules Exceptions "IO", "reals">
Submitter:   Andrew.Kennedy@persimmon.co.uk
Date:        4/11/97
Version:     109.26
System:      Alpha
Severity:    Minor
Problem:     The code should fail to elaborate
Code:        
  structure STR :> sig exception E end = struct val E = Overflow end

Transcript:  Error: Compiler bug: SigMatch:matchVElem.2
Comments:    None  
Fix:         
Test: bug1190.sml
Owner: dbm
Status: fixed in 109.27 [dbm, 4/16/97]
----------------------------------------------------------------------
Number: 1191
Title: pattern matching in presence of datatype replication
Keywords: datatype replication, pattern matching
Submitter: Tore Jahn Bastiansen <toreba@ifi.uio.no> 
Date: 4/15/97
Version: 109.26
System: -
Severity: major 
Problem: 
  Match compiler is not properly handling a match over constructor(s)
  imported into a structure via a datatype replication declaration.
Code:
  structure S =
  struct
    datatype d = D | E  (* d must have more than one constructor *)
    and h = H of d
  end;

  structure A =
  struct
    datatype h = datatype S.h
  end

  fun f (S.H x) = true;
  fun g (A.H x) = true | g _ = false;
  fun g1 (A.H x) = true; 
  fun h (A.H x) = true | h (S.H x) = false;

  val a = S.H(S.D);
  val b = A.H(S.D);
  val f_a = f a;
  val g_a = g a;
  val h_a = h a;
  val f_b = f b;
  val g_b = g b;
  val h_b = h b;
  val g1_a = g1 a;
Transcript:
  - use "bug1191.sml";
  [opening bug1191.sml]
  structure S :
    sig
      datatype d = D | E
      datatype h = H of d
    end
  structure A :
    sig datatype h = H of ?.d end
  val f = fn : S.h -> bool
  val g = fn : S.h -> bool  <-- should yield redundant match warning
  bug1191.sml:<nullRegion> Warning: match nonexhaustive  <-- bogus!
	    H x => ...

  val g1 = fn : S.h -> bool
  bug1191.sml:<nullRegion> Warning: match redundant   <-- expected
	    H x => ...
      -->   H x => ...

  val h = fn : S.h -> bool
  val a = H D : S.h
  val b = H D : S.h
  val f_a = true : bool
  val g_a = false : bool    <-- bogus!
  val h_a = true : bool
  val f_b = true : bool
  val g_b = false : bool    <-- bogus!
  val h_b = true : bool
  val it = () : unit
  uncaught exception TopLevelException [nonexhaustive match failure]
    raised at: bug1191.sml:14.18  <-- compiling g1 a

Comments:
Fix:
Test: bug1191.sml
Owner: dbm
Status: fixed in 109.27
----------------------------------------------------------------------
Number: 1192
Title: datatype replication not implemented inside of expressions
Keywords: datatype replication
Submitter: Dave MacQueen
Date: 4/15/97
Version: 109.26.1
System: -
Severity: major 
Problem: In elabcore, function elabDec', the case for DatatypeDec does
  not deal with datatype replication.
Code:
  datatype d = D;
  let datatype t = datatype d in () end;
Transcript:
  - datatype d = D;
  datatype d = D
  - let datatype t = datatype d in () end;

  uncaught exception in compiler: nonexhaustive match failure
    raised at: elaborate/elabtype.sml:234.43
	       elaborate/elabcore.sml:549.36
	       elaborate/elabcore.sml:549.36
	       elaborate/elabcore.sml:549.36
	       ...
Comments:
Fix: add the missing case
Test: bug1192.sml
Owner: dbm
Status: fixed in 109.27 [dbm, 4/16/97]
----------------------------------------------------------------------
Number: 1193
Title:       Memory leak due to ref cells
Keywords:    ref cells, dereferencing, memory leak
Submitter:   Chris Stone, cstone+@cs.cmu.edu
             Edo Biagioni, esb+@cs.cmu.edu
Date:        4/15/97
Version:     109.25.2, 109.26
System:      alpha-osf1v3.2c
Severity:    major
Problem:     

A loop which should run in constant space causes the virtual
storage required by the program to grow with no apparent bound.

Code:        

structure Leak =
 struct
  local

   type T = {field: unit}

   val data = {field = ()}

   fun monitor n = 
        if (n mod 10000 = 1) then
	 (print "starting garbage collection...";
	  SMLofNJ.Internals.GC.doGC 0;
	  SMLofNJ.Internals.GC.doGC 0;
	  print " done\n")
	else
	 ()

   val handlers = ref ((fn _ => ()): T -> unit)
  in
   fun run n : unit =
        (handlers := ! handlers; (* comment this line out for no leak *)
	 (! handlers) data;   (* comment this line out for much faster leak *)
	 monitor n;
	 run (n + 1))

  end
 end

Transcript:  <transcript of exectution demonstating the bug>

  Leak.run 0;

Comments:

We measured virtual memory size by using the following shell script,
which records the size of the ML process at approximately 5-second
intervals.  (It assumes there is only one such process running on the
machine).

#! /bin/csh -f
set f = ./sizes
touch $f
while (1)
	set x = `ps auxwww | fgrep run | fgrep -v grep | awk '{print $5}' | tr MK '  ' | sort -n -r | head -1`
        echo $x
        echo $x >> $f
	sleep 5
end

The leak should start to become visible within several minutes.  The
rate of increase slows somewhat as time passes, but the space usage
does not appear to level off.

The code does double garbage collections because John Reppy indicated
this as a workaround for a previously-reported memory leak (having
to do with array allocation).

In tests with a more complicated piece of code from which the
above was derived, changing the type T (to unit, for example) 
caused the space leak to vanish.

A hypothesis consistent with the facts is that

     handlers := ! handlers;

adds some sort of boxing/unboxing wrapper to the function stored in
the ref cell.  This would explain why omitting the application of this
function causes the program (and the leak) to go significantly faster
and why removing the assignment or changing the type T could fix the
leak.

Comment:
 [Lorenz, 5/20/97]
  The memory leak in the presence of function refs seems to have
  been properly diagnosed by its submitter; i.e. wrapper records
  are being continually chained around the ref's value.  

  The following source and cps (for f) illustrates:

  bug:
     type T = int*int
     val handlers = ref ((fn _ => ()): T -> unit);
     fun f _ : unit =
	 (handlers := !handlers;
	  f ());

  ****starting genfrag KNOWNCHK **** 
  v696(v741[I],v740[PV]) =
     !(v740) -> v625[F]
     {RK_ESCAPE 2,(L)v697,v625} -> v698
     boxedupdate(v740,(I)0,v698)
     !(v740) -> v670[F]
     {RK_ESCAPE 2,(L)v705,v670} -> v706
     boxedupdate(v740,(I)0,v706)
     !(v740) -> v674[F]
     {RK_ESCAPE 2,(L)v713,v674} -> v714
     boxedupdate(v740,(I)0,v714)
     !(v740) -> v678[F]
     {RK_ESCAPE 2,(L)v721,v678} -> v722
     boxedupdate(v740,(I)0,v722)
     (L)v696((I)0,v740)
  (* wrapper functions deleted *)


  nobug:
     type T = int;
     val handlers = ref ((fn _ => ()): T -> unit);
     fun f _ : unit =
	 (handlers := !handlers;
	  f ());

  ****starting genfrag KNOWNCHK **** 
  v946(v959[I],v958[PV]) =
     !(v958) -> v888[F]
     boxedupdate(v958,(I)0,v888)
     !(v958) -> v929[F]
     boxedupdate(v958,(I)0,v929)
     !(v958) -> v930[F]
     boxedupdate(v958,(I)0,v930)
     !(v958) -> v931[F]
     boxedupdate(v958,(I)0,v931)
     (L)v946((I)0,v958)

 [Zhong, 5/21/97]
  Thanks for diagnosing it for me, Lorenz. I didn't read the comments
  section of their bug report. 

  Yes, when we do "handlers := !handlers", a pair of wrap and unwrap
  operations are inserted, they should ultimately cancel out from 
  each other, but occasionally, the eta-reduction code in cpsopt
  leave some eta-redexes un-reduced --- causing a trivial closure 
  being built each time. 

  Your above code actually works ok in pre-109.28 (because of more aggressive
  front-end optimizations), though the code in the original bug report
  still does not work quite right. I'll look into it and fix it in 109.28.

 [Zhong, 8/15/97]
  I modified the CPS optimizer to be more aggressive on reducing the eta
  redex. This fixes the bug 1193 --- but ideally, I should do a fix that
  can guaranttee the following:

     For any ref cell x of type "\tau ref",  the expression "x := !x"
     should not introduce extra heap allocations.

  The new CPS optimizer will handle most of type \tau, but I can't
  prove that it can make such guaranttee.

  I have some idea how the "ideal" fix should be like. For the time being,
  I'd suggest that we add the above comments to bug 1193, still leave it 
  as open, but down-grade its priority to Medium.
Fix: *
Test: *
Owner: Zhong
Status: open
----------------------------------------------------------------------
Number: 1194
Title:     Compiler bug: TypesUtil: extractDcons
Keywords:  datatype replication, error message
Submitter: Vladimir Gapeyev
Date:      04/16/97
Version:   109-26, 109-26.1
System:    Solaris
Severity:  moderate?
Problem:   Attempt to replicate a datatype from a structure which is a
  functor argument, generates CompilerBug.
Code:      
  signature FOO = 
  sig
    type 'a t
  end

  functor Make (structure Foo : FOO) = 
  struct
    datatype p = datatype Foo.t
  end

Transcript:
use "bug.sml";
[opening bug.sml]
Error: Compiler bug: TypesUtil: extractDcons

uncaught exception Error
  raised at: util/errormsg.sml:51.14-51.19
             elaborate/elabmod.sml:1231.7
             elaborate/elabmod.sml:1112.33
             util/stats.sml:164.40
             build/evalloop.sml:120.38
             build/evalloop.sml:191.58
             build/evalloop.sml:283.46-283.49

Comments:
 [dbm, 4/16/97]
  This particular code would not work because the type t in the
  signature FOO is not specified as a datatype, but a proper error
  message should be generated.
Fix: check that rhs is datatype in elabmod and elabsig.
Test: bug1194.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/20/97]
----------------------------------------------------------------------
Number: 1195
Title:       wrong unit type for CharVector.app
Keywords:    signature matching
Submitter:   Elsa L. Gunter, elsa@research.bell-labs.com
Date:        4/17/1997
Version:     109.26.1
System:      Pentium Pro 200-linux2.0
Severity:    minor
Problem:     The type of CharVector.app doesn't match
                    elem -> unit -> vector -> unit
             because unit and General.unit aren't recognized as the same.
Code:

  structure A :
    sig
      eqtype vector
      type elem
      val app : elem -> unit -> vector -> unit
    end = CharVector;

Transcript:
  Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled]
  - structure A :
    sig
      eqtype vector
      type elem
      val app : elem -> unit -> vector -> unit
    end = CharVector;
  stdIn:17.1-22.19 Error: value type in structure doesn't match signature spec
      name: app
    spec:   ?.CharVector.elem -> ?.unit -> ?.CharVector.vector -> ?.unit
    actual: (?.CharVector.elem -> ?.General.unit)
	    -> ?.CharVector.vector -> ?.General.unit
  - 

Comments:

If I replace app by appi then the problem goes away.

  Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled]
  - structure A :
    sig
      eqtype vector
      type elem
      val appi : (int * elem -> unit) -> vector * int * int option -> unit
    end = CharVector;
  structure A :
    sig
      type  vector = string
      type  elem = char
      val appi : (int * elem -> unit) -> vector * int * int option -> unit
    end

Fix:
Test: bug1195.sml
Owner: jhr, erg
Status: not a bug
----------------------------------------------------------------------
Number: 1196
Title: discrepencies between Basis implementation and documentation
Keywords: Basis
Submitter: Elsa Gunter
Date: 4/17/97
Version: 109.26.1
System: -
Severity: major 
Problem: 
  The following is a list of things missing from sml-nj.109.26.1 which
  the standard basis requires.

  The structure General is missing:

      type ref
      exception Chr

  The structure Char is missing:

      type string
      val fromCString : string -> char option
      val toCString : char -> string

  The structure StringCvt has the wrong datatype declaration for realfmt.
  It should be:

      datatype realfmt
	  = SCI of int option
	  | FIX of int option
	  | GEN of int option
	  | EXACT

  The structure String is missing:

      structure Char : CHAR
      val extract : (string * int * int option) -> string
      val map : (Char.char -> Char.char) -> string -> string
      val fromCString : string -> string option
      val toCString :string -> string

  The structure Substring is missing:

      structure String : STRING
      val extract : (string * int * int option) -> substring
      val join : substring * substring -> substring


  The structure Vector is missing:

      val mapi : (int * 'a -> 'b) -> 'a vector * int * int option -> 'b vector
      val map : ('a -> 'b) -> 'a vector -> 'b vector

  The structure CharVector is missing:

      val mapi : (int * elem -> elem) -> vector * int * int option -> vector
      val map : (elem -> elem) -> vector -> vector

  The structure TextIO is missing:

      val scanStream : ((Char.char,StreamIO.instream)StringCvt.reader ->
	    ('a,StreamIO.instream)StringCvt.reader) -> instream ->
	    'a option
Comments:
Fix:
Test:
Owner: jhr, erg
Status: fixed in 109.31
----------------------------------------------------------------------
Number: 1197
Title: type sharing not propagated
Keywords: modules, functors, opaque constraints, type sharing
Submitter: Bob Harper
Date: 4/18/97
Version: 109.25.1
System: -
Severity: major 
Problem: 
  1. Type sharing is not propagated.  If I instantiate Interp with a structure
  AbSyn, then invoke Interp.evaluate on something from AbSyn, I get a type
  error in the second case, but not the first.  The problem remains if I
  extend the "where type" list to stipulate equality of all types in the
  signature.

  2. When instantiating Interp in the second form, I get:

  - structure Interp = Interp (structure A = AbSyn);
  *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11]
  *** Warning for compiler writers: PATHtyc bind. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.12]
  *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11]
  *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11]
  *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11]
  *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11]
  *** Warning for compiler writers: PATHtyc expr. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.8]
  *** Warning for compiler writers: PATHtyc expr. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.8]
  structure Interp :
    sig
      structure AbSyn : <sig>
      val evaluate : AbSyn.expr -> AbSyn.expr
    end

  3. We desperately need a structure analogue of where type!  I'd like to write

	  INTERP where AbSyn = A

  rather than write out all the type patching.
Code: bug1197.sml
Transcript:
  Standard ML of New Jersey, Version 109.25.1, February 26, 1997 [CM; autoload enabled]
  - use "test/src/t98.sml";
  [opening test/src/t98.sml]
  signature ABSYN =
    sig
      datatype expr = Int of int

    end
  signature INTERP =
    sig
      structure AbSyn :
	sig
	  datatype expr = Int of int

	end
      val evaluate : AbSyn.expr -> AbSyn.expr
    end
  functor Interp : <sig>
  structure Absyn :
    ABSYN
  *** Warning for compiler writers: PATHtyc expr. in translate: [#G47a.2,#G47a.1,#Gd47.2]
  *** Warning for compiler writers: PATHtyc expr. in translate: [#G47a.2,#G47a.1,#Gd47.2]
  structure E :
    sig
      structure AbSyn : <sig>
      val evaluate : AbSyn.expr -> AbSyn.expr
    end
  test/src/t98.sml:27.1-27.32 Error: operator and operand don't agree (tycon mismatch)
    operator domain: expr
    operand:         Absyn.expr
    in expression:
      E.evaluate (Int (3 : int))

  uncaught exception exception Error
    raised at: build/evalloop.sml:103.44-103.52
	       build/evalloop.sml:120.38
	       build/evalloop.sml:191.58
	       build/evalloop.sml:273.46-273.49
  - 
Comments:
Fix:
Test: bug1197.sml
Owner: dbm
Status: fixed in 109.26.1
----------------------------------------------------------------------
Number: 1198
Title: unnecessary "?." in printed type name
Keywords: types, printing
Submitter: Allen Stoughton <allen@cis.ksu.edu>
Date: 4/18/98
Version: 109.27
System: -
Severity: major 
Problem: 
  The type of a value exported from an abstype is printed with
  a "?". 
Code:
  abstype foo = A with val x = A end;
Transcript:

  Standard ML of New Jersey, Version 109.26, March 25, 1997
  - abstype foo = A with val x = A end;
  type foo
  val x = - : ?.foo

 But x had type foo in 109.25: 

  Standard ML of New Jersey, Version 109.25, February 1, 1997
  - abstype foo = A with val x = A end;
  type foo
  val x = - : foo

Comments: printed ok in 109.25
Fix: call of trueValType for printing variable types was removed somewhere
  after 109.25. I restored the call of trueValType inside of ppVal.
Test: bug1198.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 4/30/97]
----------------------------------------------------------------------
Number: 1199
Title: size of exportFn image
Keywords: exportFn, image size
Submitter: Nikolaj Bjorner <nikolaj@Theory.Stanford.EDU>
Date: 5/2/97
Version: 109.27
System: -
Severity: major 
Problem: exportFn image sizes have grown since 108.
Code: 
  (* 108: *)

  structure Test = 
  struct

  fun dummy(_,[name]) = 
      (print ("Hi I am "^name^"\n"))

  fun export() = 
      exportFn("/step/sml-108/bin/.heap/hi",dummy)

  end


  (* 109.27 *)

  structure Test = 
  struct

  fun dummy(name,_) = 
      (TextIO.print ("Hi I am "^name^"\n");
       OS.Process.success)

  fun export() = 
      SMLofNJ.exportFn("/step/sml/bin/.heap/hi",dummy)

  end

Comments:
  The sizes of the exported images were:

  108:
  -rw-rw----   1 nikolaj    196292 May  1 22:42 hi

  109.27
  -rw-rw----   1 nikolaj    500824 May  1 22:38 hi.sparc-solaris

  For larger executables the situation gets even worse. I 
  reported an image size of more than 35 MB in 109.27 compared
  to approx 13 MB in 108.

 [Zhong, 5/2/97]
  This difference seems to be caused from changes in the runtime
  system, as even the image for a null function is about this 
  big. 

     fun export1() = SMLofNJ.exportFn("xxx1", dummy);
     fun export2() = SMLofNJ.exportFn("xxx2", fn _ => 0);

  -rw-r--r--   1 shao     systems   449616 May  2 09:38 xxx1.sparc-solaris
  -rw-r--r--   1 shao     systems   433232 May  2 10:55 xxx2.sparc-solaris

  I also checked the runtime closures for both the dummy function and
  the "fn _ => 0" function, they all contain minimum amount of 
  free variables.

  |> For larger executables the situation gets even worse. I 
  |> reported an image size of more than 35 MB in 109.27 compared
  |> to approx 13 MB in 108.
  |>
  |> Is there any way to improve on this situation?

  This could be caused by completely different reasons from the previous.
  Sorry for keeping asking this, but if you can ship us the entire 
  source code, we can probably take a look and narrow the problem down
  for you.
Fix:
Test:
Owner: jhr
Status: fixed in 109.31 [jhr, Zhong, 9/15/97]
----------------------------------------------------------------------
Number: 1200
Title: where type problem, rhs within current signature
Keywords: modules, signatures, where type
Submitter: Robert Findler <robby@cs.rice.edu>
Date: 5/4/97
Version: ?
System: -
Severity: major 
Problem: 
  A functor using a definitional type spec in the parameter signature
  works, while an equivalent version using "where type" fails with 
  uncaught exception Unbound.
Code:
  signature S = sig
    type t
  end;

  functor F1(structure X : S
	     structure Y : sig type t = X.t
			   end) =
  struct
    val x = 1
  end;

  functor F2(structure X : S
	     structure Y : S where type t = X.t) =
  struct
    val x = 1
  end;

Transcript:
  - use "test/bugs/bug1200.sml";
  [opening test/bugs/bug1200.sml]
  signature S =
    sig type t end
  functor F1 : <sig>

  uncaught exception Unbound
    raised at: elaborate/elabmod.sml:1143.39-1143.49
	       util/stats.sml:164.40
	       build/evalloop.sml:120.38
	       build/evalloop.sml:191.58
	       build/evalloop.sml:283.46-283.49

Comments:
Fix: In finalize in explore_tclass, when there is an "external" (i.e.
  where clause) definition, characterize it as NINST instead of INST,
  and remove the call to simplify (so that instToTyc will deal with
  it properly.
Test: bug1200.sml, bug1201.sml
Owner: dbm
Status: fixed in 109.28 [dbm, 5/18/97]

root@smlnj-gforge.cs.uchicago.edu
ViewVC Help
Powered by ViewVC 1.0.0