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 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 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 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) [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 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: ls -l /bin/bc -rwxr-xr-x 1 root daemon 35584 Apr 12 1994 /bin/bc* ls -l bin/sgmls.sh -rwxr-xr-x 1 jhr jhr 185 Jan 15 14:25 bin/sgmls.sh* /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 [] 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 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 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 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 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 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" 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 (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 : structure Parameters : structure Terms : structure TermSubst : structure ParmSubst : structure Sequent : structure PrimitiveRule : 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 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 -- 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 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 : 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 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 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 => ) 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" 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 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 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 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 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 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 "" rather than "" Keywords: printing, top-level Submitter: Allen Stoughton 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 's rather than as fn's? - op o; val it = : ('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 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 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 [] 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 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 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 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 : - 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 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 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 (* 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 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 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 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 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 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 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 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 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 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: sour