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: sources.cm:: --------------------------- Group is a.sml b.sml --------------------------- a.sml:: --------------------------- signature AS = sig val a: int -> int end functor AF ():> AS = struct (* local *) val x = 1 (* in *) fun a n = n + x (* end *) end ---------------------------- b.sml:: ---------------------------- structure B = struct structure A = AF () val b = A.a 10 end ---------------------------- [Blume, 4/21/97: cutoff compilation still broken] The following example breaks cutoff recompilation. Un-commenting the type definition within functor AF causes b.sml to be recompiled: sources.cm:: ---------------------------- Group is a.sml b.sml ---------------------------- a.sml:: ---------------------------- signature AS = sig val a: int -> int end functor AF ():> AS = struct (* type ttt = unit *) fun a (x: int) = x end ---------------------------- b.sml:: ---------------------------- structure B = struct structure A = AF () val b = A.a 10 end ---------------------------- [Zhong, 4/21/97] This really depends on whether ttt is used (or referred) by function a or not [rather, appears in a's interface type-dbm]. The current compiler considers all types can potentially be used, so it can definitely be optimized. [Matthias Blume, 4/21/97] I don't understand this. Whether ttt is used in a or not shouldn't matter. I can see that there might be problems if it becomes part of a's type. But even then, suppose a depends on tttt, but a certain change to tttt does not change the type of a. In this case cutoff compilation should also work (imo). Example: functor ...: sig val a: unit -> int end = struct type foo = unit (* changes to foo do not change the type of a *) type ttt = int * foo fun a () = let val x: ttt = (3, ()) in #1 x end end [Zhong, 4/21/97] You are right. Unfortunately, the current static representations of the functor body is too coarse-grain to identify these differences. We'll see how to improve on this in the future. [Matthias, 4/30/97] Bug 1106 has been fixed, although I am personally not quite satisfied with the current status. The example that I submitted is now processed correctly. But adding, deleting, or changing any type declarations in a functor's body (even when they are masked away by a signature contraint) will cause changes in the static environment, therefore in the pickle, and will therefore cause unnecessary recompilation. Zhong said that that's an artifact of the current implementation strategy. [dbm, 5/1/97] We'll have to work on this, and I hope we can eliminate any sensitivity to internal types. Is the current effect caused by changes in the lambda types, Zhong? [Zhong, 5/1/97] No, it has nothing todo with lambda types. The functor body entity declaration currently faithfully record every type declaration it encounters --- so if any internal type declaration changes, the functor body entity expressions will change, thus the functor signature. If we want to get fancy, we can minimize the body entity expressions by throwing away all the unreachable type declarations, but this can be tricky to implement though. Owner: Andrew, dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1107 Title: Io exception in compiler Keywords: Io, Interrupted system call. Submitter: nikolaj@cs.stanford.edu Date: 11.11.96 Version: 109.21.1 System: Solaris Severity: Problem: The compiler raises the following exception: uncaught exception in compiler: Io: input failed on "", Interrupted system call raised at: boot/NewIO/text-io-fn.sml:132.14-132.56 elaborate/frontend.sml:119.24 util/stats.sml:168.40 build/evalloop.sml:232.54 It is repeated until selecting CTRL-C Code: bug1107.sml I am not sure where this happens, but functions that are used include: OS.FileSys.openDir, closeCir, readDir, isDir, isLink Comments: The bug is hard to reproduce which points to os specific problems. We have a file browser that reads directories and sorts files from directories, then lists them in separate boxes. Note also that OS.FileSys.isDir raises a SysErr exception when the path is not a directory (instead of returning false). Try for instance: OS.FileSys.isDir "/c/is/my/favorite/language/because/I/love/to/add/pointers/"; assuming you do not have such strange directories. [jhr] I think this was because they were mixing CML and SML/NJ's I/O. Test: bug1107.sml Owner: John Status: not a bug ---------------------------------------------------------------------- Number: 1108 Title: String.maxSize missnamed as String.maxLen Keywords: basis Submitter: Lorenz Huelsbergen Date: 11/8/96 Version: 109.21.1 Severity: minor Fix: change the name Owner: John Status: fixed in 109.26 [Lal, jhr, 3/29/97] ---------------------------------------------------------------------- Number: 1109 Title: boxity exception Keywords: datatypes, representation, printing Submitter: Chris Paris Date: 11/19/96 Version: 109.21.1 System: sparc/solaris (SunOS 5.5), mipseb/irix Severity: major Problem: values of a datatype cause Boxity exception or core dump. Transcript: Standard ML of New Jersey, Version 109.21.1, November 4, 1996 - datatype 'a lyst = NIL | CONS of ('a * 'a lyst) ref; datatype 'a lyst = CONS of ('a * 'a lyst) ref | NIL - val a = CONS (ref ("foo", NIL)); uncaught exception in compiler: exception Boxity raised at: boot/system.sml:133.34-133.40 util/pp.sml:554.6 build/evalloop.sml:232.54 and again -- Standard ML of New Jersey, Version 109.21.1, November 4, 1996 - datatype 'a lyst = NIL of string | CONS of ('a * 'a lyst) ref; datatype 'a lyst = CONS of ('a * 'a lyst) ref | NIL of string - val a = CONS (ref ("foo", NIL "nil")); Process sml bus error Test: bug1109.1.sml, bug1109.2.sml Owner: dbm Status: fixed in 109.23 [109.19m] ---------------------------------------------------------------------- Number: 1110 Title: problem printing datatype Keywords: datatypes, printing Submitter: Chris Paris Warning: match nonexhaustive nil => ... val f = fn : 'a list -> int (2) - local fun f [] = 1 in val x = 3 end; stdIn: Warning: match nonexhaustive nil => ... val x = 3 : int - local val x = 3 in fun f [] = x end; stdIn: Warning: match nonexhaustive nil => ... val f = fn : 'a list -> int Comments: It seems to be defined (modulo accuracy of line numbers) for local definitions in a top-level let expression or in a top level function declaration. Test: bug1112.1.sml, bug1112.2.sml, bug1112.3.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1113 Title: inappropriate error message for missing @SMLload arg Keywords: error message, heap image Submitter: John Reppy (Kent Lee ) Date: 1/7/96 Version: 109.22 Severity: major Problem: User used the wrong syntax for the @SMLload command line option and got an inappropriate error message. Transcript: sml @SMLload "genesis" filename /usr/local/sml109.22/bin/.run/run.mipseb-irix5: Fatal error -- incorrect byte order in heap image Comments: The image file genesis was created by exportFn. The command line should have been sml @SMLload=genesis filename This error should have been detected and a more appropriate error message should be given. Owner: jhr Status: fixed in 109.28 [jhr] ---------------------------------------------------------------------- Number: 1114 Title: installing prettyprinter for type created by a functor Submitter: Elsa L. Gunter Date: 7 January 1997 Version: 109.22 System: linux, version 2.0 Severity: major Problem: When a type is first defined in a functor, and then you apply the functor to get a structure, and then install a pretty-printer for the type, the installed pretty-printer is ignored. Code: (* File: pp_bug.sml *) functor TYPE () = struct datatype ty = Tyc of string end; structure Type = TYPE(); (* structure Type = struct datatype ty = Tyc of string end; *) structure P = struct fun pp_type ppstrm (Type.Tyc tyname) = (Compiler.PrettyPrint.begin_block ppstrm Compiler.PrettyPrint.CONSISTENT 0; Compiler.PrettyPrint.add_string ppstrm tyname; Compiler.PrettyPrint.end_block ppstrm) end; val _ = Compiler.PPTable.install_pp ["Type","ty"] P.pp_type; val test_type = Type.Tyc "bool"; Transcript: sml Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled] - use "pp_bug.sml"; use "pp_bug.sml"; [opening pp_bug.sml] functor TYPE : structure Type : sig datatype ty ... (hidden constructors) end structure P : sig val pp_type : ?.ppstream -> ?.ty -> unit end val test_type = Tyc "bool" : ?.ty val it = () : unit - Comments: The problem goes away (ie. the installed pretty-printer is used) if you just define the type in a structure from the begining. Fix: Test: bug1114.1.sml, bug1114.2.sml Owner: dbm Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1115 Title: vector pattern matching bug Keywords: vectors, pattern matching Submitter: Greg Morrisett (jgm@cs.cornell.edu) Date: Jan. 30, 1996 Version: 109.24 System: Win-NT Severity: severe Problem: Compiling the following file causes a Compiler bug: LambdaType: wrong TC_TUPLE in tc_select. Code: fun f #[1] = 0 | f _ = 1; Transcript: - use "test.sml"; [opening test.sml] Error: Compiler bug: LambdaType: wrong TC_TUPLE in tc_select Fix: change to translate/matchcomp.sml in 109.25 Test: bug1115.sml Owner: Zhong Shao Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1116 Title: performance problems in top level loop Keywords: performance, top-level Submitter: Larry Paulson Date: 11/26/96 Version: 109.21 System: ? Severity: major Problem: I'm afraid I'm having serious problems with performance in version 109.21. My overnight Isabelle runs, which take under three hours under Poly/ML and just over 3 1/2 hours with 108.5, are taking upwards of 10 hours (yes, 10) with 109.21. I also noticed this interactively yesterday, when a Poly/ML job started later on a slower computer finished before the same job under 109.21. These runs consist almost entirely of execution, not compilation. I find this rather discouraging, especially in that I have gone to a lot of trouble to port Isabelle to a recent version. What do you think could be wrong? ======= followup, 11/26/96 Here are some elapsed time for building some of the various modules. (All times are cumulative, measured from the start of the job.) 109.21 Poly/ML 3.1 Pure: 5 minutes 3 minutes [mostly compilation] FOL+ZF: 3:31 hours 22 minutes [mostly proofs] HOL: 9:28 hours 1:18 hours [mostly proofs] HOL would have suffered from being in competition with Poly/ML. (The SML/NJ job starts at 22:00, while the Poly/ML one starts at 04:00. Normally 6 hours is much more than enough.) The true slowdown is much worse than a factor of three, as you can see. Compatibility problems (such as calls to makestring) made the 109.21 job crash shortly after building HOL. One particular example (ZF/ex/CoUnit) takes 70 seconds (including 1.6 seconds for GC) with 109.21, against 5.2 seconds with Poly/ML. The machine is a Sun SuperSPARC with 200+ meg. Comments: Almost certainly due to top-level loop overhead, probably associated with maintenance of modmap in SCStaticEnv, i.e. running SC to often on too large a static environment. Zhong is working on a fix: Dave, this is consistent with what I have found. The sml-cm compiler has the "CM" and "CMB" module in its top-level interactive environment. Both CM and CMB are huge structures. Everytime, we do a top-level compilation (thus doing the SCEnv.concatEnv), the old environment is being un-SCed and then SCed again; and simplying SC-ing the "CM" and "CMB" structures would take huge amount of time (around 0.7 sec on Sparc20). In 109.23m (the version I sent to you), I introduced some lazy-concat on modmaps. This helps relieve the problem a bit, but not completely. I a better fix though: the top-level env will always be SCStatenv, the result of elaborate should always be bare statEnv, the "concatEnv" operating should SC the new bare statEnv in the old modmap --- this will avoid rebuilding the old modmap over and over again. After we do this, we can do reference counting on modmap to eliminate the potentional space-leak problem (similar to what Matthias did in stalePid). Fix: streamline modmap management env/scstatenv.sml build/evalloop.sml build/compile.sml Fix the BUG 1116 about very slow top-level interactive loop, reported by Larry Paulson (Dave, if you have HOL with you, can you test this out?) Test: isabelle, HOL Owner: Dave, Zhong, Matthias Status: (check) fixed in 109.25.1 ---------------------------------------------------------------------- Number: 1117 Title: SIGINT handling Keywords: signals, SIGINT Submitter: Tore Jahn Bastiansen Date: 11/27/96 Version: 109.21.1 System: sparc/solaris Severity: major Problem: There seems to be a problem with signal handeling in sml/nj 109.21.1 After recovering from Control-C, SML does not shut down properly. The signals is also passed on to the parent process. Transcript: This script, 'status', prints exit status, and, if the 1st argument is 'trap', it traps SIGINT. ---------------------------------- #!/bin/sh if [ "trap" = $1 ] then trap "echo Trapped SIGINT" 2 shift fi CMD=$1 shift $CMD $* echo Exist status: $? ---------------------------------- I have tested it on the toplevel loop on sparc-solaris ~ #45>status sml-cm Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload enabled] - OS.Process.exit 1; Exist status: 1 ~ #46>status sml-cm Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload enabled] - ^C Interrupt - OS.Process.exit 1; [No output from status] ~ #47>status trap sml-cm Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload enabled] - OS.Process.exit 1; Exist status: 1 ~ #48>status trap sml-cm Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM; autoload enabled] - ^CTrapped SIGINT <------------- Interrupt - OS.Process.exit 1; Exist status: 130 On mipseb-irix, Control-C makes an infinite loop printing uncaught exception in compiler: Io: input failed on "", I/O error raised at: boot/NewIO/text-io-fn.sml:132.14-132.56 elaborate/frontend.sml:119.24 util/stats.sml:168.40 build/evalloop.sml:232.54 The following program has similar problems: exception SigInt fun test() = let val oldHandler = Signals.inqHandler Signals.sigINT fun loop() = loop() in let val intcont = SMLofNJ.callcc(fn k => (SMLofNJ.callcc(fn k' =>(SMLofNJ.throw k k')); raise SigInt)) val newHandler = Signals.HANDLER(fn _ => intcont) in Signals.setHandler(Signals.sigINT,newHandler); loop() end handle SigInt => (Signals.setHandler(Signals.sigINT,oldHandler); print "Hello World!\n") end Comments: [jhr, 11/27/96] This is strange, and I'll look into it. BTW, the fact that your shell script also receives the signal is just because it is in the same process group as SML. SIGINT is delivered to all of the processes in the group associated with the tty. [jhr, 3/7/97] I think that what is happening is that the ^C kills the shell script, but the SML process is still running. This is why there is no status message in the second example. The infinite loop on SGI with ^C is not reproducable. The example program provided seems to work fine. Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1118 Title: Compiler bug: 222 in prof Keywords: profiler Submitter: John Reppy Date: 11/21/96 Version: 109.21.1 System: ? Severity: major Problem: Trying to compile the compiler with profiling enabled results in the following compiler bug. Transcript: Standard ML of New Jersey, Version 109.21.1, November 4, 1996 [CM&CMB 1] val it = () : unit - Compiler.Profile.setMode Compiler.Profile.LATENT; Creating profiled version of standard library val it = () : unit - CMB.make(); [scanning boot/all-files.cm] [checking boot/CM/mipseb-unix/all-files.cm.stable ... not usable] [scanning boot/pervasives.cm] [checking boot/CM/mipseb-unix/pervasives.cm.stable ... not usable] [Cleaning out binfile directory] Recompiling boot directory... [compiling (boot) boot/assembly.sig -> bin.mipseb-unix/assembly.sig.bin] Error: Compiler bug: 222 in prof uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 - Comments: Fix: Test: Owner: Andrew Status: open ---------------------------------------------------------------------- Number: 1119 Title: excessive memory usage Keywords: memory, performance Submitter: Tore Jahn Bastiansen Date: 12/12/96 Version: 109.22 System: Sparc Ultra 1/Solaris Severity: major Problem: My problem is that some data neves seems to be freed (Or maybe it's just not returned to the operatins system). After allocating 10,000,000 integers several times, always overwriting the last one (using val it = Array.array(10000000,1);), I cannot get memory useage below 200Mb, even if I say. val it= ; If I try to compile something, or do somthing else that probably will start a major GC, this seems to add to the 200Mb. This is strange, because repeated 'Array.array(10000000,1);) will not use more than 216Mb. Real memory consumption is also large. Code: Transcript: Example (TOP: means output from the program top): GC #0.0.0.0.1.1: (0 ms) Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled] TOP: PID USERNAME PRI NICE SIZE RES COMMAND TOP: 16891 toreba -4 0 19216K 9168K ... run.sparc-sola - Array.array(10000000,1); GC #0.0.0.0.2.31: (10 ms) GC #0.0.0.1.3.36: (10 ms) val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array TOP: 16891 toreba 15 0 59496K 48632K ... - Array.array(10000000,1); GC #0.0.0.1.4.64: (1050 ms) GC #0.0.0.2.5.72: (910 ms) GC #0.0.0.2.6.85: (880 ms) val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array TOP: 16891 toreba -25 0137800K 127464K ... GC #0.0.1.3.7.108: (1050 ms) val it = [|1,1,1,1,1,1,1,1,1,1,1,1,...|] : int array TOP: 16891 toreba 35 0216032K 138544K ... - 0; GC #0.0.1.3.8.145: (890 ms) val it = 0 : int Here, it uses 250MB for a second, and then goes down to 216MB No matter what I do here, I can't free much memory. Comments: Probably same as 1131. Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1120 Title: profiling on Linux Keywords: profiler Submitter: Anthony Shipman Date: 1/5/97 Version: 109.22 System: x86/Linux Elf Severity: major Problem: I enable profiling with val _ = Compiler.Profile.setMode Compiler.Profile.ACTIVE; and the report has 0 for all cumsecs values. Comments: [JHR, 1/4/97] This works for me (Linux 2.0), but I did discover a different bug with the reset function: sml Standard ML of New Jersey, Version 109.22, December 7, 1996 [CM; autoload enabled] - structure P = Compiler.Profile; structure P : PROFILE? - P.setMode P.LATENT; Creating profiled version of standard library val it = () : unit - fun f 0 = 1 | f x = (f(x-1); f(x-1)); val f = fn : int -> int - (P.setMode P.ACTIVE; f 15; P.setMode P.NOPROF; P.report TextIO.stdOut); %time cumsec #call name 100.00 .02 65535 f val it = () : unit - P.reset(); val it = () : unit - (P.setMode P.ACTIVE; f 20; P.setMode P.NOPROF; P.report TextIO.stdOut); uncaught exception SysErr: no count array set Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1121 Title: internal data constructor of abstype is exported Keywords: abstype, abstract type Submitter: Cons T Ahs Date: 1/14/97 Version: 109.23 Severity: major Problem: The constructor for an abstype is visible outside the abstype definition. Transcript: Standard ML of New Jersey, Version 109.23, January 1, 1997 [CM; autoload enabled] - abstype foo = bar of int with fun foo x = bar x end; type foo val foo = fn : int -> ?.foo - bar; val it = fn : int -> foo Comments: Fix: Test: Owner: zhong Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1122 Title: secondary error: Compiler bug: InlInfo ... Keywords: secondary error Submitter: George Russell Date: 1/15/97 Version: 109.24 System: alpha/OSF1 v4 Severity: minor Problem: secondary compiler bug error message Transcript: - signature a=sig val b:int end abstraction c:a=struct end; stdIn:16.31-16.57 Error: unmatched value specification: b Error: Compiler bug: InlInfo: Wrong field in INL_STR ! Comments: Fix: Test: bug1122.sml Owner: Zhong Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1123 Title: secondary error: nongeneralizable type variable Keywords: secondary error Submitter: Allen Stoughton Date: 1/15/97 Version: 109.24 Severity: minor Problem: secondary error: nongeneralizable type variable Transcript: - #"a" ^ "a"; stdIn:12.1-12.11 Error: operator and operand don't agree (tycon mismatch) operator domain: string * string operand: char * string in expression: ^ (#"a","a") stdIn:12.1-12.11 Error: nongeneralizable type variable it : 'Z Comments: Fix: basics/unify.sml Improve the type-checking error messages; fix BUG 1149, 1123 reported by Allen Stoughton. Test: Owner: dbm Status: fixed in 109.25.1 ---------------------------------------------------------------------- Number: 1124 Title: exception STRANGE raised by compiler Keywords: modules, functors, printing Submitter: Kenneth Cline Date: 1/15/97 Version: 109.24 System: alpha32x-osf1 Severity: major Problem: exception STRANGE raised by compiler Code: (bug1124.sml) signature F = sig type word val u: word end functor L (structure Base: sig type word end val u: Base.word) = struct datatype word = W of Base.word val u = W u end (* struct *) structure W': F = L (structure Base = Word32 val u = 0w0:word32); structure s = W'; Transcript: % sml Standard ML of New Jersey, Version 109.24, January 9, 1996 [CM; autoload enabled] - use "mbug.sml"; [opening mbug.sml] signature F = sig type word val u : word end functor L : structure W' : F? printing PATHtyc:[#G85d.8,#G85d.7,#G85d.6] --- word. uncaught exception exception STRANGE raised at: translate/transtypes.sml:167.22-167.29 util/stats.sml:168.40 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Comments: This case was fixed in 109.25. But Mikael Pettersson later reported the following test case that is still causing the bug in 109.25. signature SIG = sig datatype t1 = C1 datatype t2 = C2 and t3 = C3 | C4 of t1 end; functor F(structure S : SIG) = struct fun f(S.C4 _) = true | f x = x=x end; Another case reported by Scott Draves is found in bug1124.3.sml. Fix: translate/transtypes.sml A temporary fix for the exception STRANGE bug, BUG 1124. A better fix would require the faithful instantiation of datatypes in functor signatures. Test: bug1124.1.sml, bug1124.2.sml, bug1124.3.sml Owner: Zhong Status: fixed in 109.25.1 (temp) ---------------------------------------------------------------------- Number: 1125 Title: Unbound raised instead of proper error for sig inside functor Keywords: modules, signatures, functors Submitter: Kenneth Cline Date: 1/17/97 Version: 109.24 System: alpha32x-osf1 Severity: minor Problem: Unbound raised instead of proper error for a signature definition inside a functor body, which is now illegal. Code: (bug1125.sml) functor Tcp () = struct structure Tcp_Connection = struct type port = unit datatype t = L of {l: port} end type port = Tcp_Connection.port signature LISTEN_EXTENSION = sig datatype t = L of {l: port} end structure Listen_Extension:LISTEN_EXTENSION = Tcp_Connection end; Comments: This is illegal now, so an appropriate error message should be issued for the improper occurrence of the signature declaration. Adding "type port = port" to the body of LISTEN_EXTENSION (bug1125.1.sml) changes the error to Error: Compiler bug: ExpandTycon: expandTycon 2 Fix: Test: bug1125.sml, bug1125.1.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1126 Title: subscript error in prettyprinting Keywords: printing, top level Submitter: Andrew Appel Date: 1/21/97 Version: 109.24 System: alpha32x/osf1 Severity: major Problem: printing nil generates uncaught exception subscript out of bounds. Code: val x = nil Transcript: - val x = nil; uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:417.28-417.33 print/ppobj.sml:344.20 print/ppobj.sml:344.20 util/pp.sml:545.6 build/evalloop.sml:190.58 Comments: Caused by the change in representation of polymorphic constants, which are now functions. Fix: print/ppobj.sml Fix the pretty-printing bug, BUG 1126 and BUG 1130, on polymorphic constants such as [] and NONE. Test: bug1126.sml Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1127 Title: TextIO.canInput type does not match Basis Library Keywords: input, canInput Submitter: Andrew Appel Date: 1/21/97 Version: 109.24 System: Alpha / OSF1 Severity: major Problem: The SML/NJ implementation of TextIO.canInput does not match the signature given in the Basis Library documentation. I am not sure which one is right. SML/NJ: canInput: instream * int -> int option Basis Doc: canInput: instream * int -> bool Comments: The SML basis documentation is out of date; SML/NJ is correct. Owner: jhr Status: not a bug ---------------------------------------------------------------------- Number: 1128 Title: TextIO.canInput raises Io exception WouldBlock Keywords: input, canInput Submitter: Andrew Appel Date: 1/21/97 Version: 109.24 System: alpha-OSF1 Severity: major Problem: canInput raises an exception if input would block Transcript: - TextIO.canInput(TextIO.stdIn,1); uncaught exception Io: canInput failed on "" with exception exception WouldBlock raised at: boot/IO/text-io-fn.sml:102.14-102.56 boot/IO/text-io-fn.sml:263.29 Comments: Please note: In the following circumstances, canInput seems to be doing the right thing (modulo the possible incorrect return type). - val f = TextIO.openIn "chap1.sml"; val f = - : ?.instream - TextIO.canInput(f,1); val it = SOME 1 : int option - TextIO.canInput(f,100); val it = SOME 100 : int option - TextIO.canInput(f,100000); val it = SOME 607 : int option - val g = TextIO.openIn "/dev/null"; val g = - : ?.instream - TextIO.canInput(g,1); val it = SOME 0 : int option - Fix: (not tested) In text-io-fn.sml, line 263, replace BAD: handle WouldBlock => SOME(amount - n)) GOOD: handle IO.Io{cause=WouldBlock,...} => SOME(amount-n)) Make a similar fix on line 257 of bin-io-fn.sml. Test: Owner: jhr Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1129 Title: dereference of dangling pointer Keywords: runtime, memory Submitter: Lorenz Huelsbergen (lorenz@research.bell-labs.com) Date: 1/22/97 Version: 109.* at least System: all Severity: severe Problem: dereference of dangling pointer Code: compiling the compiler on win32 Comments: The file src/runtime/memory/mem-common.ins contains the following code that dereferences "obj" _after_ having been freed: /* MEM_FreeMemObj: */ void MEM_FreeMemObj (mem_obj_t *obj) { if (obj == NIL(mem_obj_t *)) return; UnmapMemory(obj); FREE_MEMOBJ (obj); VMSizeB -= obj->sizeB; } /* end of MEM_FreeMemObj */ where FREE_MEMOBJ(p) is defined as FREE(p) in memory/mem-mmap.c and FREE(p) is defined as _FREE(p) in include/ml-base.h and _FREE(p) is further defined (also in include/ml-base.h) as the C runtime's "free". Unfortunately this bug does not reduce memory consumption. At peak, compiling the compiler under 109.24 requires >89Mb of memory (virtual+physical, x86-linux). Owner: jhr Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1130 Title: printing datatype value Keywords: printing, datatypes Submitter: Andrew Wright Date: 1/23/97 Version: 109.24 System: - Severity: major Problem: Printing a value of a datatype at top level causes "Compiler bug: PPObj: switch: none of the datacons matched" Transcript: Standard ML of New Jersey, Version 109.24, January 9, 1996 - datatype ('a,'b) Goo = A of 'a | B of 'b; datatype ('a,'b) Goo = A of 'a | B of 'b - A 1; Error: Compiler bug: PPObj: switch: none of the datacons matched Another instance from Mary Fernandez: - structure x = struct type ord_key = string val compare= String.compare end; - structure y = BinaryMapFn(x); - open y; open y structure Key : ORD_KEY? uncaught exception in compiler: exception Boxity raised at: boot/system.sml:115.27-115.33 print/ppobj.sml:344.20 print/ppobj.sml:344.20 print/ppobj.sml:344.20 print/ppobj.sml:344.20 util/pp.sml:545.6 build/evalloop.sml:190.58 Another instance from Chris Okasaki causing subscript out of bounds: - structure L = struct val empty = [] end; structure L : sig val empty : 'a list end - open L; open L uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:417.28-417.33 print/ppobj.sml:344.20 print/ppobj.sml:344.20 util/pp.sml:545.6 build/evalloop.sml:190.58 Comments: Related to bug 1126. [Zhong Shao: 1/30/97] This seems to be related to the bug reported by Andrew. The pretty-printer can't handle polymorphic constants in 109.24. For example, val x = nil; will trigger the above message too. Polymorphic constants in 109.24 are represented as functions, i.e., "nil" will be a function takes a type value and return 0. I did not figure out a way to pretty-print such values yet. Fix: print/ppobj.sml Fix the pretty-printing bug, BUG 1126 and BUG 1130, on polymorphic constants such as [] and NONE. Test: bug1130.sml Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1131 Title: Failure to reclaim garbage Keywords: garbage collection, arrays, large heaps Submitter: Matthias Blume (blume@cs.princeton.edu) Date: Jan 26, 1997 Version: 109.19 (probably all 109.*) System: x86-linux, alpha-osf1, ... (probably all) Severity: major Problem: Garbage collector doesn't free up memory previously by large arrays. Code: fun listGarbage () = let fun g 0 = [] | g n = 0 :: g (n - 1) val data = g 100000 in hd data end fun arrayGarbage () = let val data = Array.array (1000000, 0) in Array.sub (data, 0) end fun loop f = (f (); loop f) Transcript: When running `loop listGarbage;' I get the following information from `top' on the DEC Alpha. The SIZE and RES fields settle quickly and then stay the same: PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND 8902 blume 51 0 25296K 13467K run 0:27 91.30% run.alpha32-os When running `loop arrayGarbage;' I get a growing heap... PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND 8902 blume 42 0 25296K 10428K WAIT 1:22 9.80% run.alpha32-os PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND 8902 blume 45 0 55312K 31948K run 1:30 11.40% run.alpha32-os PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND 8902 blume 42 0 63120K 33488K run 1:34 17.50% run.alpha32-os ... Comments: loop listGarbage; runs in constant space -- as one would hope and expect. However, loop arrayGarbage; runs out of virtual memory REALLY quickly, or rather, the machine comes to a virtual standstill because of the paging. [jhr, 1/26/97] This is not what is going on. The garbage is being collected, it is a problem the sizing of heaps and VM. I suspect that if you look at the amount of live data in the heap (as opposed to the amount of VM that the OS has allocated to the process), you would see constant space. These problems should be reduced when the new run-time comes online (by the end of Feb, I hope). [jhr, 2/19/97] I looked into bug #1131, which is the growing heap size when allocating large arrays, and I think I understand what is going on. BTW, there is arrayGarbage does roughly 5 times more allocation per call than listGarbage. The story is that in the current collector, large arrays are allocated in the first generation. When the first generation gets full, the GC sees that the array arena is completely full, and so allocates a somewhat larger arena for to-space. Although only one (or zero) arrays actually get copied to to-space, the same thing will happen at the next GC (i.e., the array arena will be full and the GC will try to grow it). While there is a limit on the growth of arenas, the minimum size must be large enough to hold all the potentially live data plus the extra space neede for the large array allocation which triggered the GC. This is basically a pathological case for the current sizing policy, and I don't think that there is an easy fix. The new GC will not suffer from this problem, since the to-space memory is allocated lazily. Fix: new runtime Workaround: Force a collection prior to allocation, or periodically force two collections in a row. Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1132 Title: ExpandTycon 2 Keywords: modules, type constructors Submitter: Greg Morrisett (jgm@cs.cornell.edu) Date: Jan. 27, 1996 Version: 109.24 System: Win-NT Severity: severe Problem: Compiling the following file causes an uncaught exception expandTycon 2. Code: signature FOO = sig type TyVar structure TVResult: sig datatype T = IMP_OK | FAULT of TyVar list end end; Transcript: - use "test.sml"; [opening test.sml] Error: Compiler bug: ExpandTycon: expandTycon 2 uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 elaborate/elabmod.sml:1080.33 util/stats.sml:168.40 build/evalloop.sml:119.38 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Comments: Fix: Test: bug1132.sml Owner: Zhong, dbm Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1133 Title: "" in non-exhaustive match warning messages Keywords: error messages Submitter: John Reppy Date: 1/29/97 Version: 109.24 System: - Severity: minor Problem: I've noticed several "" regions in non-exhaustive match warning messages. Can we do better than this? Transcript: [compiling ../core-cml/sync-var.sml -> ../core-cml/CM/mipseb-unix/sync-var.sml.bin] ../core-cml/sync-var.sml: Warning: match nonexhaustive transId as ref (TRANS tid) => ... This match is in a function binding at the top-level of a structure. Here is a simple example: Standard ML of New Jersey, Version 109.24, January 9, 1996 [CM&CMB 1] val it = () : unit - structure S = struct = fun f [] = 1 = end; stdIn: Warning: match nonexhaustive nil => ... Comments: Fix: Test: bug1133.sml Owner: dbm, zhong Status: fixed in 109.32 [Andrew, 10/1/97] ---------------------------------------------------------------------- Number: 1134 Title: uncaught exception MapF Keywords: CM Submitter: John Reppy Date: 1/29/97 Version: 109.24+ System: - Severity: major Problem: When trying to compile the latest version of CML on a modified version of 109.24, I get the following uncaught exception: ... [wrote Sockets/CM/mipseb-unix/cml-generic-sock.sml.bin] uncaught exception exception MapF raised at: env/dynenv.sml:36.30-36.37 I also checked this with 109.24 and I get the same error. Comments: [Matthias]: This seems to be due to a bug in the new implementation of environments. Zhong already complained about this. CM does filtering on environments (environment + list of symbols -> new environment only containing those bindings from the old one that bind symbols in the list) for the case that one uses export filters in CM's description files. This used to work perfectly in pre-109.24 versions, still works with static environments, but occasionally runs into the error above when dealing with full environments. [JHR]: I just realized that this is this problem with structure Foo = CML_Foo needing to be rewritten as structure Foo = struct open CML_Foo end Fix: Owner: Zhong?, dbm Status: fixed in 109.25.1 [Zhong] ---------------------------------------------------------------------- Number: 1135 Title: CM compiling files that haven't changed Keywords: CM Submitter: John Reppy Date: 2/1/97 Version: 109.25 System: SGI Severity: major Problem: I've noticed some unexpected messages from CM recently, where it says that it must recompile stuff that I know hasn't changed since it was last compiled. Lal has seen this too. Here is an example from a clean install of 109.25 on an SGI. The first of these comes during the compile of the CML library; the second during the compile of eXene. Transcript: ... [recovering ../src/Unix/CM/mipseb-unix/run-cml.sml.bin... failed] !% CM Warning: need to recompile ../src/Unix/run-cml.sml (even though it is `stable') [compiling ../src/Unix/run-cml.sml (stable) -> ../src/Unix/CM/mipseb-unix/run-cml.sml.bin] !* WARNING: ../src/Unix/run-cml.sml (stable) was modified after being analyzed. !* ------- (It might be necessary to re-run the analysis.) [wrote ../src/Unix/CM/mipseb-unix/run-cml.sml.bin] [compiling trace-cml-sig.sml -> CM/mipseb-unix/trace-cml-sig.sml.bin] ... [starting dependency analysis] [dependency analysis completed] [recovering ../src/Unix/CM/mipseb-unix/run-cml.sml.bin... failed] !% CM Warning: need to recompile ../src/Unix/run-cml.sml (even though it is `stable') [compiling ../src/Unix/run-cml.sml (stable) -> ../src/Unix/CM/mipseb-unix/run-cml.sml.bin] !* WARNING: ../src/Unix/run-cml.sml (stable) was modified after being analyzed. !* ------- (It might be necessary to re-run the analysis.) [wrote ../src/Unix/CM/mipseb-unix/run-cml.sml.bin] [starting dependency analysis] [dependency analysis completed] Comments: [Matthias, 2/1/97] I suspect that this is due to some not-quite-synchronized clocks between host machine and fileserver, since I am unable to reproduce this effect here. But I will look into it. [JHR, 2/2/97] Unlikely, since the machine I was building on is the file server. Also, the source file should be days older than the bin file. BTW, do you cache timestamps? [Matthias, 2/19/97] I have the sneaking suspicion that bugs 1106, 1135, and 1154 are really all the same bug or at least very closely related. Test: Owner: Blume Status: open ---------------------------------------------------------------------- Number: 1136 Title: sharing causes a type to loose its equality property Keywords: modules, sharing, equality Submitter: Nikolaj Bjorner Date: 2/4/97 Version: 109.25 System: - Severity: major Problem: The new version 109.25 does not inherit eqtype when it is shared with a non-eqtype as the following example illustrates. Examples like these used to compile under 109.23. Code: signature TS1 = sig eqtype t val f : t -> t end signature TS2 = sig type t end functor SF(structure T1:TS1 and T2 : TS2 sharing type T1.t = T2.t) = struct fun test t = T1.f t = t fun test ts = List.map T1.f ts = ts end Transcript: - use "bug1136.sml"; [opening bug1136.sml] signature TS1 = sig eqtype t val f : t -> t end signature TS2 = sig type t end bug1136.sml:18.16-18.26 Error: operator and operand don't agree (equality type required) operator domain: ''Z * ''Z operand: ?.t * ?.t in expression: = (T1.f t,t) bug1136.sml:19.17-19.38 Error: operator and operand don't agree (equality type required) operator domain: ''Z * ''Z operand: ?.t list * ?.t list in expression: = (List.map T1.f ts,ts) uncaught exception exception Error raised at: build/evalloop.sml:102.44-102.52 build/evalloop.sml:119.38 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Comments: Fix: Test: bug1136.sml, bug1136.1.sml Owner: dbm Status: fixed in 109.27 [dbm -- but it is a hack] ---------------------------------------------------------------------- Number: 1137 Title: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h Keywords: modules, functors, sharing Submitter: Nikolaj Bjorner Date: 2/4/97 Version: 109.25 System: - Severity: major Problem: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h Transcript: functor FooFUN(structure CC : CONG_CLOSURE sharing type CC.term = Expr.expr and type CC.node_type = tyopt) = struct end Error: Compiler bug: TransTypes: unexpected FORMAL kind in tycTyc-h uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:168.40 sched/recompile.sml:196.38-196.41 Comments: [Bjorner, 2/23/97] As noticed earlier, I have not been able to reproduce the bug even when uncommenting the code that caused it. (I had avoided the bug by turning a functor into a structure and copying it.) Some other change I made to the source must have avoided it. I can therefore not give better indications on what causes the bug. [Zhong, 2/25/97] I ran into another bug today that is most likely the same bug that caused the above. I have fixed it in 109.25+, and the code will be incorporated into 109.25.1. Fix: Test: Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1138 Title: undefined signature generates secondary error Keywords: secondary error Submitter: Nikolaj Bjorner Date: 2/4/97 Version: 109.25 System: - Severity: minor Problem: undefined signature leads to "Compiler bug: ModuleUtil: tycId" secondary error. Code: functor F(structure T : SIGNOT_DEFINED) = struct fun test() = () end Transcript: Error: Compiler bug: ModuleUtil: tycId Comments: [DBM, 2/12/97] I get a different compiler bug: - use "bug1138.sml"; [opening bug1138.sml] bug1138.sml:3.25-3.39 Error: unbound signature: SIGNOT_DEFINED Error: Compiler bug: Instantiate: lookSlot uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:168.40 ... Fix: Test: bug1138.sml Owner: dbm Status: fixed in 109.28 [dbm, 4/29/97] ---------------------------------------------------------------------- Number: 1139 Title: Compiler bug: Translate: unexpected type variables in mkPE Keywords: Submitter: Nikolaj Bjorner Date: 2/4/97 Version: 109.25 System: - Severity: major Problem: Compiler bug: Translate: unexpected type variables in mkPE Code: val f = let fun g(t,arg as {a = [],e = e}) c = let val str = arg in () end in () end [or, Zhong's version:] fun g (arg as []) = let val str = arg in () end A temporary get-around will add an explicit type constraint after [], e.g. "arg as [] : 'a list". Transcript: Comments: Fix: typing/typecheck.sml Fix the bug, BUG 1139, on "unexpected type variables in mkPE" reported by Nikolaj (a.k.a. BUG 4 in his list of four bugs for 109.25) Test: bug1139.1.sml, bug1139.2.sml Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1140 Title: signature decl causes Compiler bug: ExpandTycon: expandTycon 2 Keywords: modules, signatures Submitter: Nikolaj Bjorner Date: 1/14/97 Version: 109.24 System: - Severity: major Problem: Compiling a signature declaration causes "Compiler bug: ExpandTycon: expandTycon 2". Code: (reduced by Zhong Shao) signature BUTTON_VECTOR = sig type key structure R : sig datatype s = Toggle of key end end Transcript: - use "bug1140.sml"; [opening bug1140.sml] Error: Compiler bug: ExpandTycon: expandTycon 2 uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 elaborate/elabmod.sml:1080.33 util/stats.sml:168.40 build/evalloop.sml:119.38 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Test: bug1140.sml Owner: Zhong, dbm Status: fixed in 109.25 ---------------------------------------------------------------------- Number: 1141 Title: functor decl produces Compiler bug: ExpandTycon: expandTycon 2 Keywords: modules, functors Submitter: Zhong Shao Date: 2/13/97 Version: 109.25 System: - Severity: major Problem: Compiling a functor decl causes "Compiler bug: ExpandTycon: expandTycon 2". Code: Transcript: - use "bug1141.sml"; [opening bug1141.sml] Error: Compiler bug: ExpandTycon: expandTycon 2 uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 elaborate/elabmod.sml:993.8 elaborate/elabmod.sml:1209.7 elaborate/elabmod.sml:1097.33 ... Comments: This is a variant of the code in bug 1125. Fix: [dbm] added entEnv parameter to expandTycon. Test: bug1141.sml Owner: Zhong, dbm Status: fixed in 109.25.1 [dbm] ---------------------------------------------------------------------- Number: 1142 Title: size of exportFn image Keywords: exportFn, image size Submitter: Tore Jahn Bastiansen Date: 2/4/97 Version: 109.25 System: sparc/solaris Severity: major Problem: exporftFn image size increased dramatically between 109.22 and 109.25. I have been using both versions 109.22 and 109.25 on sparc-solaris. When compiling with 109.25 the heap image generated by SMLofNJ.exportFn seems to be a lot bigger: 109.25 -rw-r----- 1 toreba 9913224 Feb 4 10:05 abel.sparc-solaris 109.22 -rw-r----- 1 toreba 1267888 Feb 4 10:22 abel.sparc-solaris BTW. I also get small differences on an UltraSparc compared to a Sparc-20. Even when the runtime and library sources are exactly the same and no compiling is done (only recovering and linking via CM). ========== Also noted by Peter Bertelsen (pmb@dina.kvl.dk): SMLofNJ.exportFn("dummy", fn (rt, args) => OS.Process.success) : unit; Even a trivial function like the one exported above produces a huge heap image (a bit larger than the original heap image for the entire compiler): dummy.x86-linux : 8942172 bytes sml-cm.x86-linux : 8724948 bytes Transcript: Comments: [jhr]The implementation of exportFn is tricky (making sure that everything that everything that is not needed is stripped away). We must have broken something in going from 109.22 to 109.25. Did you try your program with 109.23 or 109.24 by any chance? [jhr, with regard to UltraSparc/Sparc-20 differences] Have you tried both orders (i.e., compile on SS20 and then load on US vs. compile on US and load on SS-20)? [Zhong] I checked your code on my sparc 20, it seems to work out ok with the bare sml or sml-cm compiler (See attached, the image is about 0.6Mbytes). I did see the problem if I run "sml" with CML loaded, it looks like that when we do exportFn, we are also exporting all the newly loaded environment (from CM). We'll fix this in the next release. [Mathieas] > You are the second person to report this bug. Clearly, something was broken > in the 109.24, but I don't know what. I'm also curious as to why CML stuff > is being autoloaded, when you haven't mentioned CML. He _did_ mention it: CML exports a structure OS. [jhr] |> In message <199702061723.SAA03299@ellemose.dina.kvl.dk>, Peter |> Michael Bertelsen wri tes: >> >> > You are the second person to report this bug. Clearly, something >> was broken > in the 109.24, but I don't know what. I'm also >> curious as to why CML stuff > is being autoloaded, when you haven't >> mentioned CML. >> >> I requested AUTOLOAD_CML when the compiler was built; didn't know that >> this would make a difference. As for the huge images, I have now >> tried to rebuild the compiler without CML; this brings the image size >> for the trivial `dummy' example down to 652k (on Linux). |> |> So what is happening is that the reference to OS.Process is being viewed as |> a reference to CML's version of that. Even without the CML stuff, this |> image is twice as large as in 109.23. [Zhong] In 109.24, I have temporarily turned off the structure-access lifting; this seems to be a bad idea. For a function such as fun f x = OS.Process.success in 109.24, the closure for "f" would contain a reference to the entire structure OS rather than to the actual field "OS.Process.success", thus leading to the leak above. Fix: translate/translate.sml Putting back the access-lifting code to avoid the "exportFn image blowup" bug --- BUG 1142. Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1143 Title: Word.andb combined with toInt broken on x86 Keywords: Word, x86 Submitter: Manuel Fahndrich Date: 04/02/97 Version: 109.25 System: x86/Linux Severity: major Problem: Word.andb followed by Word.toString gives wrong answer Code: val maskr = ref 0wx3fff; Word.andb (!maskr, 0wxfffffff); Word.toInt (Word.andb (!maskr, 0wxfffffff)); Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled] - val maskr = ref 0wx3fff; val maskr = ref 0wx3fff : word ref - Word.andb (!maskr, 0wxfffffff); val it = 0wx3fff : word - Word.toInt (Word.andb (!maskr, 0wxfffffff)); val it = ~1073725441 : int Comments: Works without the explicit dereference. [Zhong]This seems to be caused by something in the implementation of the new "testu_31_31" primop. It works in version 109.15 (which uses realu31_i31 primop) but fails in 109.22 (which uses the testu_31_31 primop) to do the Word.toInt conversion. ======================== [Lal] testu_31_31 looks correct. There appears to be some interaction with references that triggers this bug, because: val x = 0wx3fff; Word.toInt x; gives the correct answer, but: val x = ref 0wx3fff; Word.toInt (!x); generates a wrong answer. This bug does not occur on the alpha or hppa, so it must be code generator related. ======================= [jhr] It fails in 109.23 on the MIPS, so I suspect that it is a bug in generic. ======================= [Lorenz] It first appears in the transition from 109.17 to 109.18. Here's a simpler test: - fun f x = Word.toInt x; val f = fn : word -> int - f 0w0; val it = ~1073741824 : int - Word.toInt 0w0; val it = 0 : int - I suspect contract.sml, in particular the lines (in 109.25): | PURE(P.copy(p,n), [v], x, t, e as ARITH(a, [v2], x2, t2, e2)) => let val v' = [ren v] fun skip () = PURE(P.copy(p,n), v', x, t, g' e) fun checkClicked(tok, n2, m, class, arithOp) = if cvtPreCondition(n, n2, x, v2) then (click tok; class(arithOp(p,m), v', x2, t2, g' e2)) else skip() in case a of P.test(n2,m) => if m >= p then checkClicked("C5", n2, m, PURE, P.copy) else checkClicked("C6", n2, m, ARITH, P.test) | P.testu(n2,m) => if m >= p then checkClicked("C7", n2, m, PURE, P.copy) else checkClicked("C8", n2, m, ARITH, P.testu) | _ => skip() end I read this as: "a P.copy followed by a P.testu will remove the testu if the copy contains the size of the testu args (and some other stuff)." I don't see why it's safe to remove an overflow check here. What invariant guarantees that this check gets done elsewhere? Note that (p = n = n2 = m = 31) will remove the testu. Before compiling a compiler that changes this (see my next sml-bugs message) to see if it's indeed the bug, perhaps the writer of this code would be so kind to check my reading of it. ======================= [Lal] Well, the bug is really in the mips code generator. testu_31_31 is implemented in generic as: | ARITH(P.testu(31, 31), [v], x, _, e) => alloc(x,any,fn x' => let val vreg = gpregbind v in M.addt(vreg,gpregbind(INT32 0wx80000000), x'); M.move(vreg, x'); gen e end) The M.addt traps on overflow and does the necessary range check. If no overflow takes place, then the M.move copies the argument (vreg) into the result register x'. However, The implementation of M.move among other things has something like this: fun move(Direct a, Direct b) = (case (reg_rep a, reg_rep b) of .... | (Reg' a', Reg' b') => if a'=b' then () else emit(M.ADD(b,a,RegOp0))) .... Now if vreg is identical to x', then the copy is _not_ performed!! Hence the bug. QED. ====================== [Lorenz] >> Zhong wrote: >> >> > This seems to be caused by something in the implementation of >> >> > the new "testu_31_31" primop. It works in version 109.15 (which >> >> > uses realu31_i31 primop) but fails in 109.22 (which uses the >> >> > testu_31_31 primop) to do the Word.toInt conversion. >> > >> Lal responds: >> >> testu_31_31 looks correct. >> >> > >> John says: >> >It fails in 109.23 on the MIPS, so I suspect that it is a bug in generic. > >> Lorenz writes: >> It first appears in the transition from 109.17 to 109.18. >> Here's a simpler test: > >Well, the bug is really in the mips code generator. Well, then its in the other old code generators as well. Moreover, I don't think it's a CG bug... >testu_31_31 is implemented in generic as: > > | ARITH(P.testu(31, 31), [v], x, _, e) => > alloc(x,any,fn x' => let val vreg = gpregbind v > in > M.addt(vreg,gpregbind(INT32 0wx80000000), x'); > M.move(vreg, x'); > gen e > end) > >The M.addt traps on overflow and does the necessary range check. > >If no overflow takes place, then the M.move copies the argument (vreg) because what else should M.move do if the src and dst are the same? If it did the explicit move, that would have the same deleterious effect here. Are we certain that it's OK for generic to see a primop where the args and the destination share a common lvar? The question seems to be: why is testu(31,31) being passed an arg (v) that maps to the same register as its destination. >into the result register x'. However, The implementation of M.move >among other things has something like this: > > fun move(Direct a, Direct b) = > (case (reg_rep a, reg_rep b) > of .... > | (Reg' a', Reg' b') => > if a'=b' then () else emit(M.ADD(b,a,RegOp0))) > .... > >Now if vreg is identical to x', then the copy is _not_ performed!! Again, how would you correctly _do_ the copy in the CG if dst == src? >Hence the bug. > QED. Not convinced, Lorenz =================== [Lal] > Date: Wed, 05 Feb 1997 16:39:20 -0500 > From: Lorenz Huelsbergen > ... > I read this as: "a P.copy followed by a P.testu will remove the testu > if the copy contains the size of the testu args (and some other stuff)." > I don't see why it's safe to remove an overflow check here. What invariant > guarantees that this check gets done elsewhere? > Note that (p = n = n2 = m = 31) will remove the testu. Indeed this is a bug. The rules relating TESTU and COPY should be: TESTU(n,m) o COPY(p,n) == COPY(p,m) if (m > p) == TESTU(p,m) if (m <= p) ============== [Lorenz] Here is list of potential instances of the alloc/gpregbind bug in cps/generic.sml: | ARITH(P.testu(32, 32), [v], x, _, e) => alloc(x,any,fn x' => let val vreg = gpregbind v in M.addt(vreg,gpregbind(INT32 0wx80000000), x'); M.move(vreg, x'); gen e end) | ARITH(P.testu(31, 31), [v], x, _, e) => alloc(x,any,fn x' => let val vreg = gpregbind v in M.addt(vreg,gpregbind(INT32 0wx80000000), x'); M.move(vreg, x'); gen e end) | ARITH(P.testu(32,31), [v], x, _, e) => alloc(x, any, fn x' => let val vreg = gpregbind v val lab = newlabel() in ibranch(LEU, vreg, gpregbind(INT32 0wx3fffffff), lab); M.move(gpregbind(INT32 0wx80000000), x'); M.addt(x', x', x'); define lab; M.add(vreg, vreg, x'); M.orb(immed 1, x', x'); gen e end) | PURE(P.pure_arith{oper=P./,kind=P.UINT 32},[v,w],x,_,e) => alloc(x,any,fn x' => (M.move(gpregbind v,x'); M.divtu(gpregbind w,x'); gen e)) | ARITH(P.arith{oper=P./,kind=P.INT 32},[v,w],x,_,e) => alloc(x,any,fn x' => (M.move(gpregbind v,x'); M.divt(gpregbind w,x'); gen e)) ===================== [Lal] Actually there are more bugs of this kind lurking around particularly wrt to M.mult, M.mulu, and M.divtu. I'm amazed that we haven't tripped over them before. The fix for this is a little involved. There are two alternatives: 1. Change M.divt (and others) to be 3-address instructions. This would mean changing the implementation in all the code generators. 2. Gurantee at least two arithmetic temps. This may not be such a big problem on RISC machines (although it would be a shame to tie up a register this way), but would certainly hurt the x86. ===================== [jhr] 3. switch to the new back-end. ===================== [Lorenz] >Actually there are more bugs of this kind lurking around particularly >wrt to M.mult, M.mulu, and M.divtu. I'm amazed that we haven't tripped The primops with M.mult, M.mulu, and M.divtu (other than the above) seem OK since they use arithtemp. The problem occurs when there's a write to the alloc'd variable (x') before the last gpregbind of a variable since (as you pointed out) alloc is free to use the same register as that assigned to another lvar as long as the last use appears in this expression. Fix: Test: bug1143.sml Owner: Lal Status: fixed in 109.25.1 (Lal) ---------------------------------------------------------------------- Number: 1144 Title: exception Compile: "imported objects not found or inconsistent" Keywords: modules, structures, open Submitter: Elsa L. Gunter Date: 5 February 1997 Version: 109.25 System: linux, version 2.0 Severity: critical Problem: If you create a structure with a nested substructure, and then create another stucture with the first as a substructure, and then open the second and the refer to a component of the substructure of the first, the compiler finds inconsistent (or non-existant) objects. Code: (* File: bug1144.sml *) structure B = struct structure A = struct fun f () = () end end; structure C = struct structure B = B end; open C; fun t () = B.A.f; Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled] - use "bug1144.sml"; [opening bug1144.sml] structure B : sig structure A : end structure C : sig structure B : end open C structure B : sig structure A : end lookup 2f2acba603a0e9885fba5cbf83aaadd3 lookup fc03a1bf80706210bdd10474b667dfff uncaught exception Compile: "imported objects not found or inconsistent" raised at: build/compile.sml:39.20-39.31 util/stats.sml:168.40 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Comments: Both the open and the semicolons are important. Fix: pickle/pickmod.sml Turn off the sharing of the structure bindings, because structures with same modids may potentially have different dynamic accesses. This fixed BUG 1144 reported by Elsa Gunter. [dbm] This fix may have an unfortunate effect on the size of static environments. A better permanent fix involves separating the dynamic access field from the static structure, functor representations. Test: bug1144.sml Owner: Zhong, dbm Status: fixed in 109.25.1 (temp?) (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1145 Title: large memory consumption Keywords: memory, performance Submitter: Lorenz Huelsbergen (lorenz@research.bell-labs.com) Date: 2/5/97 Version: 109.24, 109.25 System: mipseb-irix5, x86-win32, presumably all Severity: major Problem: large memory consumption Code: compiling the compiler Comments: When compiling the compiler for versions 109.24 and 109.25, the following amounts of real and virtual memory are used: 109.24 x86-win32 109.25 x86-win32 real: 101 MB 150 MB virtual: 166 MB 199 MB These numbers come via the NT performance monitor, which can gather, among other things, per-process peak real and virtual memory usage. The virtual-memory numbers are the number of virtual bytes reserved by the process, but not necessarily allocated. On mipseb-irix5, the process sizes grow to: 109.24 mipseb-irix5 109.25 mipseb-irix5 "top"'s size: 139 MB 154 MB The mipseb-irix5 numbers were obtained by staring, for the length of the compile, at the output of "top," recording the largest value for the process "size" field, and multiplying by the OS's page size (4K). Default compiler/runtime settings were used. I'm sending this along as a major bug since it impedes coding as much, if not more, than an incorrect implementation of a compiler component (which often has a source-level work around). [jhr] I think that this can be traced to the reformat phase (at least we have some strong evidence of that). I assume that Zhong is working on a fix. Fix: [Zhong] Enclosed please find a (temporary) fix for the "reformat" bug John mentioned above. The "crazy" space blowup can occur only if you are compiling abstractions (with huge mutually recursive datatypes). In the compiler, all the space blowup happens when compiling the file profile/tell-env.sml. basics/typesutil.sml Turn off the reformating on abstract data types. Reformating can potentially leads to exponential space and time blow up (BUG 1145). [dbm] This is a temporary fix. A long term fix requires redesign of the datatype representation. Owner: Zhong Status: fixed in 109.25.1 (temp) ---------------------------------------------------------------------- Number: 1146 Title: core dump on x86/linux Keywords: core dump Submitter: Norman Ramsey Date: 2/4/97 Version: 109.25 System: x86-linux Severity: critical Problem: I include this file using use "nines.sml", something magically auto-loads the sml-nj library (cool), but the program dumps core after about a minute and a half on a Pentium 133: - Problem.dumpCore(); /usr/local/src/smlnj-109.25/bin/.run/run.x86-linux: Fatal error -- unexpected fault, signal = 11, code = 0x804cdab The machine has 80M of real memory and 80M of swap -- I don't think it's running out of memory, but you never know... Code: bug1146.sml Transcript: Comments: [jhr, 4/3/97] This bug has something to do with floating-point. The program he sent goes off in bad ways because of NaNs (which he did not expect), but there was also a problem with a bogus floating-point exception code being generated by Linux (it doesn't actually dump core). Fix: Test: bug1146.sml Owner: Lorenz Status: fixed in 109.27 [Lorenz, 4/11/97] ---------------------------------------------------------------------- Number: 1147 Title: "where type" causes nonexhaustive match failure Keywords: modules, signatures, where type Submitter: Chris Okasaki Date: 2/6/97 Version: 109.25 System: - Severity: major Problem: Trying to use the "where type" syntax in 109.25 causes a nonexhaustive match failure. Transcript: - signature S = sig type T end; signature S = sig type T end - signature S' = S where type T = int; uncaught exception in compiler: nonexhaustive match failure raised at: decl/convert.sml:189.25 build/evalloop.sml:190.58 Comments: [Mathias] This looks like it is coming from CM. Whoever patched it for use with the new front end must have left out a few cases... Fix: Test: bug1147.sml Owner: dbm, Matthias Status: fixed in 109.25.2 [Matthias] ---------------------------------------------------------------------- Number: 1148 Title: ALPHA32.PRIM.ASM floor_a still uses unimplemented instruction Keywords: Real, floor_a Submitter: Kenneth Cline Date: 2/7/97 Version: 109.25 System: alpha-osf1 Severity: minor Problem: floor_a in 109.25 uses an addt/m instruction which, like the cvtqlv it replaced, is not implemented by the processors in our alphastations 250 4/266 workstations. With the latest firmware and OSF1, executing the addt/m instruction generates a SIGILL signal, resulting in a core dump. This instruction is presumably emulated by other firmware/OS combinations, but this makes the addt/m instruction very costly to execute. Comments: Fix: Here's the version of floor_a we use. It is ugly, and its use of the stack is suspect, but something along these lines should be acceptable. ML_CODE_HDR(floor_a) ldt $f0,0(STDARG) /* get argument */ fblt $f0, 2f /* jump if argument is negative */ cvttqvc $f0,$f0 /* round to quadword */ cvtqlv $f0,$f0 /* convert quad to long */ sts $f0,-4($30) /* store temporarily into C stack */ ldl ATMP1,-4($30) /* load from C stack */ addlv ATMP1,ATMP1,ATMP2 /* make room for tag bit */ 1: bis ATMP2,1,STDARG /* add the tag bit */ CONTINUE 2: /* negative argument */ /* cvttqm (x) = cvttq (2*x - 0.5) / 2 */ /* cvttq (x-0.5) loses for odd integers which IEEE round to evens */ lda $0,0xC1E0000000000000 /* t-floating -2147483648.0 ... */ stq $0,8(sp) /* ... (minimum 31 bit signed int) */ ldt $f1, 8(sp) /* load min into $f1 */ subt $f0, $f1, $f1 /* is arg too small? */ fblt $f1, 3f /* jump if yes (underflow) */ lda $0,0x3FE0000000000000 /* t-floating -0.5 */ stq $0,8(sp) /* move via stack ... */ ldt $f1, 8(sp) addt $f0, $f0, $f0 /* compute ... */ subt $f0, $f1, $f0 /* ... 2*x + 0.5 */ cvttq $f0, $f0 /* round to int */ stt $f0, -8($30) /* move via stack ... ldq STDARG, -8($30) sra STDARG, 1 /* halve */ br 1b 3: eqv STDARG, STDARG, STDARG /* generate overflow */ sll STDARG, 63, STDARG addqv STDARG, STDARG, STDARG trapb CONTINUE Comment: same as bug 1097 Test: Owner: Lal Status: fixed in 109.25.1 (Lal) ---------------------------------------------------------------------- Number: 1149 Title: spurious "nongeneralizable type variable" messages Keywords: type checking, value restriction Submitter: Allen Stoughton Date: 2/7/97 Version: 109.25 System: - Severity: minor Problem: The spurious "nongeneralizable type variable" messages haven't completely disappeared in 109.25, as the following example shows: Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 - fun f(x, y) = x ^ y; val f = fn : string * string -> string - f "a" "b"; stdIn:8.1-8.10 Error: operator and operand don't agree (tycon mismatch) operator domain: string * string operand: string in expression: f "a" stdIn:8.1-8.10 Error: nongeneralizable type variable it : 'Z Comments: Fix: basics/unify.sml Improve the type-checking error messages; fix BUG 1149, 1123 reported by Allen Stoughton. Test: bug1149.sml Owner: dbm, Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1150 Title: secondary error - Compiler bug: ModuleUtil: fctId Keywords: modules, secondary Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 02/10/97 Version: 109.25 System: - Severity: minor Problem: calling nonexistent functor apparently doesn't abort compilation Code: Transcript: - structure S = F(); stdIn:16.15-16.18 Error: unbound functor: F (* ok *) Error: Compiler bug: ModuleUtil: fctId (* huh? *) Comments: This causes a different error (nonexhaustive match failure in modules/sigmatch:844.5) in 109.23. Fix: Test: bug1150.sml Owner: dbm Status: fixed in 109.28 [dbm, 4/29/97] ---------------------------------------------------------------------- Number: 1151 Title: equality on reals admitted Keywords: equality, reals Submitter: Andrew Kennedy Date: 2/11/97 Version: 109.25 System: - Severity: major Problem: equality operation on reals is admitted without complaint. Transcript: - fun f (x,y) = (x/y, x=y); val f = fn : real * real -> real * bool Comments: Fix: Test: bug1151.sml Owner: dbm, jhr Status: fixed in 109.26 ---------------------------------------------------------------------- Number: 1152 Title: opaque signature matching with sharing looses equality property Keywords: modules, signatures, sharing, equality Submitter: George Russell Date: 2/11/97 Version: 109.25 System: - Severity: major Problem: If a type with an eqtype spec shares with a non-equality type in an opaque signature match, the first type looses its equality property. Code: (* bug1152.1.sml *) structure A :> sig eqtype t end = struct type t = int end; fun f(x: A.t) = x = x; (* works *) ========================= (* bug1152.2.sml *) structure A :> sig eqtype t structure B: sig type t end sharing type t = B.t end = struct type t = int structure B = struct type t = t end end; fun f(x: A.t) = x = x; (* should work, but doesn't *) Comments: [dbm]. This is the same bug as 1136. Fix: Each instance type should keep the same eqprop as it's spec. I believe this is the behavior specified in SML 96. Test: bug1152.sml Owner: dbm, Zhong Status: fixed in 109.27 [dbm -- but it is a hack] ---------------------------------------------------------------------- Number: 1153 Title: core dump Keywords: core dump Submitter: Nikolaj Bjorner Date: 2/11/97 Version: 109.25 System: sparc Ultra 2/Solaris Severity: critical Problem: I managed to make sml 109.25 dump core. Would you like to see the core image: -rw-rw---- 1 nikolaj 76368852 Feb 11 08:55 core I ran it with some debugging (TraceCML.xspawn) explaining the other printouts on the run. Code: Transcript: WARNING! Watched thread Color.getColor[006152] has died. xspawn Color.getColor [006156] thread Color.getColor [006154]exiting. xspawn Color.getColor [006158] thread Color.getColor [006156]exiting. WARNING! Watched thread Color.getColor[006154] has died. xspawn Color.getStipple [006160] thread Color.getStipple [005984]exiting. WARNING! Watched thread Color.getColor[006156] has died. xspawn Color.getColor [006162] thread Color.getColor [006158]exiting. WARNING! Watched thread Color.getStipple[005984] has died. xspawn Color.getColor [006164] WARNING! Watched thread Color.getColor[006158] has died. thread Color.getColor [006162]exiting. WARNING! Watched thread Color.getColor[006162] has died. xspawn Color.getColor [006166] thread Color.getColor [006164]exiting. WARNING! Watched thread Color.getColor[006164] has died. Illegal Instruction - core dumped manet> Comments: [jhr] I ran the heap image you sent me under adb, and it looks like it might be a bug in the new representation analysis (not my part of the system :). I will continue to look into the unexpected shutdown problem, which I suspect is unrelated. Zhong: there is a fairly repeatable SIGBUS error on the sparc in a big CML/eXene program. The code being executed is: bl noGC sub %g1, -0xaf8, %i3 ld [%sp+0x64], %o4 mov %g1, %o7 jmp %o4 mov 0x7f, %o5 noGC: ld [%i0+0x4], %o1 // SIGBUS here ld [%o1], %i0 jmp %i1 cmp %g6,%g4 The value of %i0 is 0xb6206fff, which is a tagged int/word. I ran this twice and got the same error (same register value) at the same address. [jhr] In message <199702132154.QAA11393@daffy.systemsx.cs.yale.edu>, Zhong Shao writes: > > > |> Tracing things down in the source-code will take some time > |> as I am chasing a couple of conference deadlines the next weeks. > |> We also have not bundeled up the code so it is ready-to-go. > |> I am not sure about what you mean by > |> "exportML a version of the compiler right before". > |> > |> nsb > > I mean "export" a binary version of the compiler (by calling > SMLofNJ.exportML). This is not practical in this case. The program in question is an eXene application. It doesn't run very long before it core dumps (two menu operations). [jhr, 2/20/97] This causes a bus error on the SGI as well. Fix: translate/wrapping.sml translate/ltycomp.sml translate/ltyprim.sml Fixing the incorrect wrapper bug, BUG 1158, reported by Ken Cline (zcline.sml). This also fixes the core dump bug, BUG 1153, reported by Nikolaj. Test: Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1154 Title: CM insists on recompiling sources in a stable library Keywords: CM, cutoff recompilation Submitter: Matthias Blume Date: 2/12/97 Version: 109.25 System: - Severity: major Problem: I just spent some time chasing a particularly persistent bug: Both Lal and John reported earlier that CM would insist on recompiling certain sources, despite the fact that the library they are in is stable and none of the sources were touched in between. However, after fixing a bug in my treatment of timestamps - something that I hoped would solve the problem - the effect did _not_ go away. I investigated further, and now it looks very much like a bug related to hashing and/or filtering of environments. Let me explain: The context for compiling or unpickling a given compilation unit is constructed by combining the delta environments obtained from compiling/unpickling its predecessors in the dependency graph. Some of those predecessors may live in a group/library that has an export filter. In this case the corresponding delta env is filtered first before it is used and its hash is (re)calculated for the purpose of compatibility checks. Unfortunately, for some reason the following property doesn't seem to hold in (at least) 109.25 (remember that pickling/hashing is always done relative to some context): hash{env=c,context=empty) = hash(env=c',context=empty) hash(env=e,context=c) = hash(env=e',context=c') f = f' -------------------------------------------------------------------- hash(env=filter(e,f),context=c) = hash(env=filter(e',f'),context=c') In words: Hashing the _same_ delta environment filtered by the _same_ filter with respect to the _same_ context yields _different_ hash values. And the effects are spurious recompilations... Environment gurus: Any ideas what's going on? Comments: [Andrew] I don't know what's going on, but I will be happy to sit down with you and we can instrument the pickler to report what the difference is between one thing and the other, so that we can track it down. [Matthias, 2/13/97] The function Signature in pickle/pickmod.sml pickles boundeps, even though a comment says it doesn't. Unfortunately, in what should be _exactly_ the same environment it sometimes is ref NONE and at other times ref (SOME ) Thus, the pickles and therefore the hash value come out differently. We once had the same problem with lty, and I went through some pretty ugly hackery to fix that. In general I would like to see all optional information that is redundant (not sure if boundeps is redundant) disappear completely from the pickled environments, because it only causes trouble there. [Zhong, 2/13/97] I was in charge of the "boundeps" stuff in Signature --- the "boundeps" itself is a hack, it should become standard (not an "option ref" anymore) once the module instantiation is implementated incrementally. For the time being, you can turn off the pickling of the boundeps field completely. Would this fix your unnecessary recompilation problem ? [Matthias, 2/19/97] I have the sneaking suspicion that bugs 1106, 1135, and 1154 are really all the same bug or at least very closely related. [Zhong, 2/20/97] The "boundeps" field could be one cause for bug 1154, but it cannot be the cause for 1106 since signatures in 109.21 do not even haven boundeps field. Fix: [Zhong, 2/26/97] pickle/pickmod.sml Turn off the pickling on the boundeps field of the signatures. If Matthias's analysis is right, this could fix BUG 1154. But I think there are other reasons to BUG 1154. Test: Owner: Andrew, Matthias Status: open ---------------------------------------------------------------------- Number: 1155 Title: type abbreviation identical to spec does not match (+ secondary) Keywords: modules, signature matching Submitter: Norman Ramsey Date: 2/13/97 Version: 109.25 System: - Severity: major? Problem: After a couple signature matching error messages, "Compiler bug: TypesUtil: tycStamp ERRORtyc" is generated. Code: signature S1 = sig type s end; signature S2 = sig structure A : S1 type t = A.s end; functor G(Y: S2) = struct open Y end; functor H(Z: S1) = struct structure B = struct structure A = Z type t = A.s end structure C : S2 = G(B) end; Transcript: - use "bug1155.sml"; [opening bug1155.sml] signature S1 = sig type s end signature S2 = sig structure A : sig type s end type t = A.s end functor G : bug1155.sml:24.3-24.26 Error: type t does not match definitional specification bug1155.sml:24.3-24.26 Error: unmatched type specification: t Error: Compiler bug: TypesUtil: tycStamp ERRORtyc uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:168.40 elaborate/elabmod.sml:993.8 elaborate/elabmod.sml:1209.7 elaborate/elabmod.sml:1097.33 ... Comments: [Ramsey, 2/19/97] Looks secondary to me too. The problem is, *I* think the code is good, and the code compiles without any error at all under 109.23. So either there's a primary error triggering all this, or else you've implemented another of those rules of SML '96 that I don't understand, in which case I'd be grateful if you'd explain to me where I've gone wrong. As far as I understand, the compiler is complaining about type 'f field_binding' = 'f * Exp.intexp not maching its definitional specification, even though the definitional specification appears identical... [dbm] Yes, definitely a bug. The bug goes away if the call of G is expanded inline, and also if the substructure A is eliminated and t is defined in terms of a constant type (e.g. type t = int). [Zhong, 2/25/97] Norman's program is caused by a problem in Instantiation, more specifically, modules/instantiate.sml When instantiating DEFtyc and GENtyc, the old code does not create a new stamp, this is wrong because the tycon in signature would then have the same tycId as its instantiation tycon. This makes two different tycons map to the same binding in the modmaps, causing a bunch of mysterious bugs. I'll send the fix to be included into 109.25.1. Fix: Test: bug1155.sml Owner: dbm, Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1156 Title: subscript raised for intmap entry that exists Keywords: Submitter: Lal George Date: 2/13/97 Version: 109.25 (bug not 109.23) System: sgi-irix5.3 Severity: major Problem: subscript raised for intmap entry that exists Code: (bug1156.sml) (** Just the regular Intmap module pulled out of the compiler. **) structure I : sig type 'a intmap val new : unit -> bool intmap val add : '2a intmap -> int * '2a -> unit val map : 'a intmap -> int -> 'a end = struct open Array List infix 9 sub datatype 'a bucket = NIL | B of (int * 'a * 'a bucket) datatype 'a intmap = H of {table: 'a bucket array ref,exn: exn} val new = fn () => H{table=ref(array(16,NIL)),exn=Overflow} fun index () = let val k = 16 (* Array.length a *) val v = Word.fromInt(k - 1) val w = Word.andb(0wx2, v) val z = Word.toInt w in z end fun map (H{table,exn}) = (fn i => let val ref a = table val nn = index () val _ = print ((Int.toString nn) ^ " nnn \n") fun find NIL = raise exn | find(B(i',j,r)) = if i=i' then j else find r in find(a sub nn) end) fun add _ _ = () end; val x = I.map (I.new()) 2; Transcript: Running it in the current compiler shows that nn is assigned a wrong value. use "bug1156.sml"; [opening bug1156.sml] structure I : sig datatype 'a intmap ... (hidden constructors) val new : unit -> bool intmap val add : 'a intmap -> int * 'a -> unit val map : 'a intmap -> int -> 'a end ~1073741822 nnn uncaught exception subscript out of bounds raised at: zintmap.sml:31.16-31.19 - Comments: [Zhong] I can't simplify the code furthermore. My guess is that it is caused by the same bug you and Lorenz have identified a few days ago, because: (1) If I change "val z = Word.toInt w" to "val z = Word.toIntX w" the bug goes away. (2) If I turn off cpsopt, the bug goes away. The bug seems to only occur for a particular sequence of word manipulation instructions (mostly likely caused by the same "move-with-same-src-and-tgt" problem) [Lal] Yes. You are right. I ran the same test case in my version of 109.25 that contained that bug fix, and it worked fine. Thanks. Fix: Test: bug1156.sml Owner: Lal Status: fixed in 109.25.1 (Lal) ---------------------------------------------------------------------- Number: 1157 Title: div and quot give incorrect answers Keywords: div, quot Submitter: Perry Cheng Date: 2/13/97 Version: 109.19, 109.23, 109.25 System: alpha-osf1(2.0) Severity: major Problem: div and quot give incorrect answers Transcript: - 7 div ~4; val it = ~3 : int - Int.quot(7,~4); val it = ~2 : int also (from Andrew Kennedy) - ~10 div 10000; val it = ~2 : int Comments: The answers should be ~2 and ~1, respectively. Fix: There is a bug in cps/contract.sml. The one line diff below should be applied, if you are familiar with recompiling the compiler; otherwise the fix will be in 109.25.1. ---------------------------------------------------------------------- diff -c -r1.2 contract.sml *** 1.2 1997/02/08 00:09:31 --- contract.sml 1997/02/14 16:27:19 *************** *** 959,965 **** | (P.arith{oper=P./,...}, [v, INT 1]) => (click "K"; v) | (P.arith{oper=P./,...}, [INT i, INT 0]) => raise ConstFold | (P.arith{oper=P./,kind=P.INT 31}, [INT i, INT j]) => ! let val x = i div j in x+x; click "L"; INT x end | (P.arith{oper=P.+,...}, [INT 0, v]) => (click "M"; v) | (P.arith{oper=P.+,...}, [v, INT 0]) => (click "N"; v) | (P.arith{oper=P.+,kind=P.INT 31}, [INT i, INT j]) => --- 959,965 ---- | (P.arith{oper=P./,...}, [v, INT 1]) => (click "K"; v) | (P.arith{oper=P./,...}, [INT i, INT 0]) => raise ConstFold | (P.arith{oper=P./,kind=P.INT 31}, [INT i, INT j]) => ! let val x = Int.quot(i, j) in x+x; click "L"; INT x end | (P.arith{oper=P.+,...}, [INT 0, v]) => (click "M"; v) | (P.arith{oper=P.+,...}, [v, INT 0]) => (click "N"; v) | (P.arith{oper=P.+,kind=P.INT 31}, [INT i, INT j]) => Test: bug1157.sml Owner: Lal Status: fixed in 109.25.1 ---------------------------------------------------------------------- Number: 1158 Title: datatype representation incorrect Keywords: datatypes, representation analysis Submitter: Kenneth Cline Date: 2/16/97 Version: 109.25 System: - Severity: major Problem: The program included below produces the wrong answer when compiled in smlnj 109.25. Instead of evaluating to 1, val should_be_one ends up as a number which is almost certainly a memory address. When compiling this program, version 109 produces the error message: abug.sml:30.16-30.31 Error: The constructor S of datatype session has different representations in the signature and the structure. Change the definition of the types carried by the constructors in the functor formal parameter and the functor actual parameter so that they are both abstract, or so that neither is abstract. This is a serious bug for us because the Fox Net has a lot of datatypes which include word32s in structures which become actual parameters to functors. In case this is a difficult bug to fix, is it possible to get the old error message back? Code: signature PROTOBUG = sig type address datatype session = S of address -> int val session: session end structure Arg = struct structure Lower = struct type address = Word32.word datatype session = S of address -> int val session = S (fn a => Word32.toInt a) end datatype address = A of Word32.word fun resolve (A host) = host end functor Connectbug (structure Lower: PROTOBUG type address val resolve: address -> Lower.address) = struct type address = address datatype session = S of address -> int val session = S (case Lower.session of (Lower.S lower_connect) => (fn address => lower_connect (resolve address))) end structure AA = Connectbug (Arg) val should_be_one = case AA.session of AA.S connect => connect (Arg.A 0w1) Transcript: - use "bug1158.sml"; [opening bug1158.sml] ... val should_be_one = 4760456 : int Comments: [Zhong, 2/17/97] Thanks for the bug report. The bug is caused by the incorrect implementation of one of the wrappers. I have fixed it in my version of 109.25+, and I'll incorporate the fix into version 109.25.1. Just curious, since pre-109.24 won't accept code like above, did you write these code recently ? FoxNet seems to be one of those applications that really require matching concrete datatype reps against abstract datatype reps. Fix: translate/wrapping.sml translate/ltycomp.sml translate/ltyprim.sml Fixing the incorrect wrapper bug, BUG 1158, reported by Ken Cline (zcline.sml). This also fixes the core dump bug, BUG 1153, reported by Nikolaj. Test: bug1158.sml Owner: Zhong Status: fixed in 109.25.1 (Zhong, 2/26/97) ---------------------------------------------------------------------- Number: 1159 Title: extraneous types included in pervasive environment Keywords: environment, pervasivies, Basis Submitter: John Reppy Date: 2/17/97 Version: 109.25 System: - Severity: major Problem: > > > structure Arg = > > > struct > > > structure Lower = > > > struct > > > type address = word32 > > > > word32 == Word32.word??? > > Yes. Type Word32.word is defined as word32 in boot/word32.sml. It seems that certain internal types (word8, word32, int32) are leaking out into the pervasive environment. This is cased by the "open PrimTypes" in boot/bind-toplevel.sml. We should replace it with rebindings of the top-level types. Code: val x : word8 = 0w8; Transcript: - val x : word8 = 0w8; val x = 0wx8 : word8 - Comments: The infrastructure to fix this already exists in bind-toplevel.sml. The bug is caused by PrimTypes being opened. Fix: Once we can say: datatype 'a ref = datatype PrimTypes.ref the line that opens PrimTypes can be removed. [jhr, 8/26/97] I did this by replacing the opening of PrimTypes in boot/bind-toplevel.sml with datatype ref = PrimTypes.ref The special properties of references (equality, etc.) still seem to hold. Test: bug1159.sml Owner: dbm, Zhong, Matthias Status: fixed in 109.31 [jhr] ---------------------------------------------------------------------- Number: 1160 Title: Compiler bug: PPAbsyn: unexpected absyn expression in ppExp' Keywords: prettyprinting Submitter: John Reppy Date: 2/17/97 Version: 109.25 System: - Severity: major Problem: "Compiler bug: PPAbsyn: unexpected absyn expression in ppExp'" generated during prettyprinting. Transcript: - val (_, x) = true; stdIn:1.1-2.13 Error: pattern and expression in val dec don't agree (tycon mismatch) pattern: 'Z * 'Y expression: bool in declaration: (_,x) = (case true of (_,x) => {1=x}) stdIn:1.1-2.13 Error: selecting a non-existing field from a record (type mismatch) the field name: 1 the record type: _ in expression:Error: Compiler bug: PPAbsyn: unexpected absyn expression in ppExp' - Comments: The compiler bug is fixed, but the form of the declaration printed in the error message is very distorted from the user's point of view. This problem is reported in 1183. Fix: Test: bug1160.sml Owner: dbm, Zhong Status: fixed in 109.27 [dbm] ---------------------------------------------------------------------- Number: 1161 Title: Win32.FileIO.getFileTime' not accessing correct time stamp Keywords: file access time, Win32 Submitter: Andrew Stevens Date: 2/17/97 Version: 109.25 System: x86-Win32 Severity: major Problem: The OS.FileIO.modTime function and the underlying Win32.FileIO.getFileTime' functions appear not to be accessing the correct time-stamp. The returned timestamp never changes when a file is written to (e.g. by editting and saving). Comments: [Lorenz] Thanks for the report. The runtime was querying for creation time, not access time; this is fixed for the next version. Fix: Test: Owner: Lorenz Status: fixed in 109.25.1 ---------------------------------------------------------------------- Number: 1162 Title: uncaught exception Io: filePosIn failed on "foo" ... Keywords: IO, TextIO Submitter: Stephen Weeks Date: 2/18/97 Version: 109.21 System: ? Severity: major Problem: uncaught exception Io: filePosIn failed on "foo" ... Transcript: Standard ML of New Jersey, Version 109.21, October 28, 1996 [CM; autoload enabled] - let val file = "foo" > val ins = TextIO.openIn file > val _ = TextIO.input1 ins > in TextIO.setPosIn(ins,TextIO.getPosIn ins) ; > TextIO.closeIn ins > end; uncaught exception Io: filePosIn failed on "foo" with exception Fail: bogus position raised at: boot/NewIO/text-io-fn.sml:132.14-132.56 Comments: I ran strace to see what was going on. Here is the snippet of the relevant part of the strace output. > open("foo", O_RDONLY) = 4 > fstat(4, {st_mode=S_IFREG|0644, st_size=23, ...}) = 0 > lseek(4, 0, SEEK_CUR) = 0 > read(4, "foo is a nonempty file\n", 4096) = 23 > lseek(4, 23, SEEK_SET) = 23 > read(4, "", 1) = 0 > getrusage(RUSAGE_SELF, {ru_utime={1, 430000}, ru_stime={0, 390000}, ...}) = 0 > write(1, "\nuncaught exception Io: filePos"..., 86) = 86 > write(1, " raised at: boot/NewIO/text-io-"..., 53) = 53 The problem is that the position returned by the call to getPosIn is wrong - it should be 1, but it appears to be 23 + 1 (as evidenced by the second lseek followed by the read). Looking at the source code (boot/NewIO/text-io-fn.sml), it looks like the function extendStream on line 139 is broken. In particular, the basePos for the new buffer is wrong, since it is computed *after* the read of the buffer, and hence points after the end, rather than at the beginning of the new buffer. Fix: Test: Owner: jhr Status: fixed in 109.25.1 ---------------------------------------------------------------------- Number: 1163 Title: Wrong match compiler warning Keywords: match compiler, redundant match, warning message Submitter: manuel@cs.berkeley.edu Date: Feb 20 97 Version: 109.25 System: x86/linux Severity: low Problem: Match compiler gives erroneous 'Redundant' warning Code: datatype t = A of int | B of int; fun f (a,b) = case (a,b) of (A i1, (B i2 | A i2)) => i1 + i2 | ((A i1 | B i1), A i2) => i1 - i2 | (B i1, B i2) => i1 * i2; Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled] - datatype t = A of int | B of int; datatype t = A of int | B of int - fun f (a,b) = case (a,b) of (A i1, (B i2 | A i2)) => i1 + i2 | ((A i1 | B i1), A i2) => i1 = = = - i2 | (B i1, B i2) => i1 * i2; = = stdIn:18.5-21.32 Warning: match redundant (A i1,(B i2 | A i2)) => ... --> ((A i1 | B i1),A i2) => ... (B i1,B i2) => ... val f = fn : t * t -> int [Another example from Perry Cheng, 2/20/97] datatype dt = A | B - fun f (A,A) = 0 = | f (B,B) = 1 = | f ((A|B),(A|B)) = 2; stdIn: Warning: match redundant (A,A) => ... (B,B) => ... --> ((A | B),(A | B)) => ... Comments: The produced code however include the case, since: - f (B 1, A 2); val it = ~1 : int Fix: Test: bug1163.1.sml, bug1163.2.sml Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1164 Title: compiler bug after failure to generalize explicit type var Keywords: type checking Submitter: Dave MacQueen Date: 3/21/97 Version: pre 109.26 System: any Severity: major Problem: a compiler bug message is generated in translate phase in code where an explicitly typed variable apparently is incorrectly generalized at it's binding declaration. Code: fun f x = (* type metavar tv(x) has depth 1 *) let fun g(y: 'a) = (* 'a is user bound tyvar scoped at g decl; depth 2 *) if true then x else y (* forces unification of 'a and tv(x) * which should reset 'a depth to 1 *) in 0 end; Transcript: - use "test/src/type1.sml"; [opening test/src/type1.sml] Error: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 translate/translate.sml:129.39 translate/translate.sml:129.39 util/stats.sml:164.40 build/evalloop.sml:191.58 build/evalloop.sml:273.46-273.49 Comments: Fix: Test: bug1164.sml Owner: dbm, Zhong Status: fixed in 109.26 [dbm] ---------------------------------------------------------------------- Number: 1165 Title: wrong type name printed for OS.Process.success Keywords: printing, types Submitter: Dave MacQueen Date: 3/21/97 Version: 109.25.2 System: - Severity: minor Problem: The top level prints the type of OS.Process.success as "?.OS_Process.status" Code: Transcript: - OS.Process.success; val it = 0 : ?.OS_Process.status - Comments: Fix: Test: bug1165.sml Owner: jhr, dbm Status: open ---------------------------------------------------------------------- Number: 1166 Title: where type causes Compiler bug: TypesUtil: tycStamp PATHtyc u Keywords: where types, signatures, modules Submitter: Zhong Shao Date: 3/23/97 Version: 109.25.2 System: - Severity: major Problem: where type causes Compiler bug: TypesUtil: tycStamp PATHtyc u Code: functor F(type u) = struct abstraction A : sig type t end where type t = u = struct type t=u end end Transcript: - use "bug1166.sml"; [opening bug1166.sml] Error: Compiler bug: TypesUtil: tycStamp PATHtyc u uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:164.40 elaborate/elabmod.sml:993.8 elaborate/elabmod.sml:1209.7 elaborate/elabmod.sml:1097.33 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:273.46-273.49 Comments: Fix: change definition of ModuleUtil.descToTyc for the EXTCONSTtyc case to interpret within DEFtyc bodies. Test: bug1166.sml Owner: dbm Status: fixed in 109.26 [dbm, 3/24/97] ---------------------------------------------------------------------- Number: 1167 Title: Compiler bug: boxity Keywords: printing, representation Submitter: Norman Ramsey Date: 3/2/97 Version: 109.23 and 109.25 System: linux Severity: minor Problem: compiler raises Boxity while loading a file. Code: bug1167.sml (original), bug1167.2.sml (reduced) Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled] - use "bugs/bug1167.2.sml"; [opening bugs/bug1167.2.sml] datatype exp = UNARY of (string * int) * int val deco = ("\^F\128\000\^F\182 q<\216\^C\160d\158\^P\000\^A\129\195\000\000\154\^P \127\218\^F\160\^D\150\^P \130\214!\160\000\240!\160\^H\218!\160\^D\176\^A\160\^D\140\^A\160\^L\129\198@\000\128\161\128\^D\000\000\000\000\000\000\000\000\000\000#", uncaught exception Boxity raised at: boot/system.sml:98.27-98.33 print/ppobj.sml:356.20 print/ppobj.sml:356.20 print/ppobj.sml:356.20 print/ppobj.sml:356.20 util/pp.sml:545.6 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: Fix: Test: bug1167.sml, bug1167.2.sml Owner: Zhong Status: fixed in 109.25.2 [Zhong] ---------------------------------------------------------------------- Number: 1168 Title: Interrupt within a 'use' Keywords: Submitter: riccardo@research.att.com Date: 03/04/1997 Version: 109.25 System: checked on x86 (Solaris 2.5.1), IRIX 5.0. Severity: minor Problem: Interrupts during the execution of 'use' produce a TopLevelCallcc exception (problem also occurs with useStream). Code: Given a file 'bug.sml' containing: fun inf () = inf (): unit; inf (); Transcript: Given the file 'bug.sml' as above, and interrupting it via a control-C produces: - use "bug.sml"; [opening bug.sml] val inf = fn : unit -> unit ^C uncaught exception in compiler: exception TopLevelCallcc raised at: build/compile.sml:330.30-330.44 util/stats.sml:168.40 build/evalloop.sml:190.58 Comments: The bug seems to be present in 109.23 as well. [jhr, 4/3/97] This is a bug in the top-level loop code. Test: * Owner: Status: open ---------------------------------------------------------------------- Number: 1169 Title: problems printing polymorphic records Keywords: printing, representation Submitter: Stephen Weeks Date: 3/8/97 Version: 109.25.2 System: - Severity: major Problem: printing a pair containing a polymorphic function produces Boxity or Subscript exception, depending on type of other component. Code: Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 [CM; autoload enabled] - (1,fn _ => 13); GC #0.0.0.0.4.167: (10 ms) uncaught exception in compiler: exception Boxity raised at: boot/system.sml:115.27-115.33 print/ppobj.sml:344.20 print/ppobj.sml:344.20 print/ppobj.sml:344.20 print/ppobj.sml:344.20 util/pp.sml:545.6 build/evalloop.sml:190.58 - ("",fn _ => 13) ; uncaught exception in compiler: subscript out of bounds raised at: print/ppobj.sml:472.20-472.25 print/ppobj.sml:344.20 print/ppobj.sml:344.20 util/pp.sml:545.6 build/evalloop.sml:190.58 - Comments: [Zhong, 3/24/97] Printing polymorphic records is still not correct. For example, val x = (3, fn _ => 4) would cause boxity errors in ppobj. Fully supporting this requires major changes in ppobj, so I temporarily turned off the pretty-printing for polymorphic records [Zhong, 4/9/97] Temporary hack prints "polymorphic record" as a stand-in. True fix requires extensive rewrite of PPVal. Fix: Test: bug1169.1.sml, bug1169.2.sml Owner: Zhong Status: open ---------------------------------------------------------------------- Number: 1170 Title: where type problem Keywords: where type Submitter: Frank Pfenning Date: 3/13/97 Version: 109.25.2 System: - Severity: major Problem: 1. The parser does not seem to like where type t1 = and t2 = which should be part of the SML'96 syntax, I believe 2. When I replace this by where type t1 = where type t2 = I get the error Error: Compiler bug: TypesUtil: tycStamp PATHtyc parse_result uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:164.40 elaborate/elabmod.sml:1097.33 util/stats.sml:164.40 sched/recompile.sml:228.38-228.41 Comments: [dbm, 3/23/97] The syntax in 1 is legal SML (according to Figure 19, p. 59 of the Revised Defn. The syntax in 2. should work, and does in simple examples I've tried (bug1170.2.sml). I haven't been able to reproduce this behavior. Fix: changed ml.grm, at the cost of adding a 2nd shift-reduce conflict! Test: bug1170.1.sml, bug1170.2.sml Owner: dbm Status: fixed in 109.27 [dbm, 4/10/97] ---------------------------------------------------------------------- Number: 1171 Title: where type on opaque functor result signature Keywords: modules, functors Submitter: George Russell Date: 3/17/97 Version: 109.26- System: - Severity: major Problem: where type clause on opaque functor result signature doesn't work. Code: functor WRef(type u):>sig type t type href val new:t->href end where type t=u = struct type t=u type href=u ref fun new x=ref x end structure WR=WRef(type u=int) val h=WR.new 0 Transcript: - use "bugs/bug1171.sml"; [opening bugs/bug1171.sml] bugs/bug1171.sml:15.1-15.15 Error: operator and operand don't agree [literal] operator domain: u operand: int in expression: WR.new (0 : int) uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 - Comments: This was fixed as a side-effect of fixing 1166. Fix: same as for 1166. Test: bug1171.sml Owner: dbm Status: fixed in 109.26 [dbm,3/24/97] ---------------------------------------------------------------------- Number: 1172 Title: error message about non-constructor in pattern needs more info Keywords: error messages, patterns, constructors Submitter: Allen Stoughton Date: 3/20/97 Version: 109.25 System: - Severity: minor Problem: The following 109.25 error message doesn't indicate the identity of the offending non-constructor (::#). Transcript: Standard ML of New Jersey, Version 109.25, February 1, 1997 - fun f (#"a"::#"b"::_) = true; stdIn:7.5-7.29 Error: non-constructor applied to argument in pattern Comments: Fix: Test: bug1172.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1173 Title: Abstraction-type-export-inconsistency Keywords: "abstraction", "ints", "types" Submitter: Thomas R. Schmidt, schmidts@tagetes.informatik.uni-stuttgart.de Date: 21/03/97 Version: 109.25 System: Linux 1.2.13 Severity: minor Problem: Types in abstractions are not always exported, so it is not possible to give a value to a function, e.g. Code: (* Author : Thomas Schmidt (schmidts@tagetes.informatik.uni-stuttgart.de) * Date : 18.03.97, 21.03.97 * System : Linux 1.2.13 * Version: 1.09.21.1 and 1.09.25 * File : sml-bugtest.sml * Use for: Test the presence of the bug that prevents types to be * exported from abstractions. *) (* First a little preparation *) signature S = sig type t end structure R: S = struct type t = real end structure I: S = struct type t = int end (* The abstraction/open combination can be replaced by the :> - Operator in * 1.09.25+. Doesn't change the behaviour, though: *) (* functor F(T:S) :> sig type t = T.t val one: T.t -> T.t val two: t -> t end = struct type t = T.t fun one t = t fun two t = t end *) functor F(T:S) = struct abstraction dummy: sig type t = T.t val one: T.t -> T.t val two: t -> t end = struct type t = T.t fun one t = t fun two t = t end open dummy end structure FI = F(I); structure FR = F(R); (* This is executed in 109.21.1 without problems. * The Problem lies here with .25. Sometimes it works, sometimes it doesn't. *) (* works under .25 *) FI.one 2; FR.one 2.0; FR.two 2.0; (* This doesn't work under .25 *) FI.two 2; Transcript: (* Stuff deleted *) val it = 2 : I.t val it = 2.0 : R.t val it = 2.0 : ?.t Error: Compiler bug: Unify: unexpected tycon in tycon_eqprop uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 typing/typecheck.sml:391.9 util/stats.sml:168.40 elaborate/elabmod.sml:1272.47 elaborate/elabmod.sml:1277.4 util/stats.sml:168.40 build/evalloop.sml:119.38 build/evalloop.sml:190.58 build/evalloop.sml:272.46-272.49 Comments: Obviously, you can work around the bug. If someone told me that earlier!-)) Fix: Test: bug1173.sml Owner: dbm Status: fixed in 109.26 ---------------------------------------------------------------------- Number: 1174 Title: Compiler bug: SigMatch:packElems: STRspec (secondary error) Keywords: secondary error, modules Submitter: Robert Findler Date: 3/26/97 Version: 109.26 System: - Severity: minor Problem: After a signature match error, "Compiler bug: SigMatch:packElems: STRspec". Code: signature sig1 = sig type t val f : int -> t end functor fun1() :> sig1 = struct type t = bool fun f(0) = false | f(n) = true end signature sig2 = sig structure str1 : sig1 type t val h : t -> int end functor fun2(structure str1 : sig1) :> sig2 = struct structure st1 = str1 type t = str1.t fun h(false) = 0 end Transcript: stdIn:34.9-39.8 Error: unmatched structure specification: str1 stdIn:34.9-39.8 Error: value type in structure doesn't match signature spec name: h spec: ?.t -> int actual: bool -> int Error: Compiler bug: SigMatch:packElems: STRspec Comments: Fix: added case tests to str and fct branches of packElems. Test: bug1174.sml, bug1174.1.sml Owner: dbm Status: fixed in 109.28 [dbm, 4/30/97] ---------------------------------------------------------------------- Number: 1175 Title: uncaught exception RegMap Keywords: core Submitter: Andrew.Kennedy@persimmon.co.uk Date: 3/27/97 Version: 109.26 System: Alpha Severity: Major Problem: "uncaught exception RegMap" upon reading file Code: (*----------------------------------------------------------------------*) (* A very general datatype for state monads *) (*----------------------------------------------------------------------*) datatype ('s, 'r) Monad = St of 's -> 'r * 's (*----------------------------------------------------------------------*) (* Wadler's unit and bind for state monads *) (*----------------------------------------------------------------------*) fun unit v = St (fn state => (v, state)) fun bind (St st) f = St (fn s => let val (v, s') = st s in let val St st' = f v in st' s' end end) (*----------------------------------------------------------------------*) (* Map with state *) (*----------------------------------------------------------------------*) fun monadmap f [] = unit [] | monadmap f (x::xs) = bind (f x) (fn y => bind (monadmap f xs) (fn ys => unit (y::ys))) Transcript: [opening test] uncaught exception RegMap raised at: util/intmap.sml:28.41-28.44 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: not quite repeatable -- sometimes get "uncaught exception in compiler: subscript out of bounds" [Lal, 3/26/97] The program below has no floating point but generates : v764(v996[PV],v995[PV],v994[C],v993[PV],v992[PV],v991[PV],v990[PV]) = {(I)0,v990} -> v601 v995.1 -> v997[I] if i31=(v997,(I)6) [v603] then funwrap((I)0) -> v604[R] funwrap(v990) -> v605[R] {RK_FBLOCK 2,v604,v605} -> v606 v994(v994,v993,v992,v991,v606) else v994(v994,v993,v992,v991,v601) What's even more weird is that it is trying to unwrap the integer constant zero into a floating point value: funwrap((I)0) -> v604[R] [dbm, 3/26/97] Works in 109.25 (on sparc-solaris), but fails in 109.25.1, so probably do to a diff between 109.25 and 109.25.1. Likely candidates are cps or translate. [Zhong, 3/26/97 These are actually dead code. Representation analysis insert wrappers (using typecase) in the front end; the CPS optimizer is not good enough to eliminate these dead code, but it does do some partial constant propagations. This leads to strange code such as funwrap ((I) 0) -> v604[R] And I am sure the code generator will complain, thus the bug. > > uncaught exception RegMap This kind of scenerio happens before, I think we still allow CPS code such as SELECT((I) 0, 0). [dbm, 4/18/95] In 109.27, behavior changes slightly but bug is still present: - use "tests/bug1175.sml"; [opening tests/bug1175.sml] uncaught exception FPRegEA raised at: cps/generic.sml:98.67-98.74 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Fix: Test: bug1175.sml Owner: Zhong Status: fixed in 109.28 [Zhong, 4/30/97] ---------------------------------------------------------------------- Number: 1176 Title: compiler bug printing type in error message Keywords: printing, types Submitter: Lorenz Huelsbergen Date: 3/26/97 Version: 109.26 System: - Severity: major Problem: While printing a type in an error message the message "Compiler bug: PPType: printTyvar" occurs. Transcript: - : canna.research.bell-labs.com 192; /usr/local/sml/109.26/bin/sml-cm Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] - fun normalize s x = (x/s); stdIn:17.23 Error: overloaded variable not defined at type symbol: / type: Error: Compiler bug: PPType: printTyvar - Comments: Fix: fill in missing cases in PPType.tyvarPrintname Test: bug1176.sml Owner: dbm Status: fixed in 109.27 [dbm, 3/27/97] ---------------------------------------------------------------------- Number: 1177 Title: inappropriate nongeneralizable type variable error Keywords: type checking, polymorphism, value restriction Submitter: John Reppy Date: 3/27/97 Version: 109.26 System: - Severity: major Problem: A type variable that should be generalized is not, resulting in an error message. Code: (* bug1177.sml *) val z = let val tbl = ref nil fun ins x = tbl := x :: !tbl in ins 1 end; Transcript: (with Compiler.Control.internals := true *) - use "bug1177.sml"; [opening bug1177.sml] bug1177.sml:4.9-4.26 Warning: value restriction prevents type variable generalization : 'Z.M[10000000] bug1177.sml:5.2-5.30 Error: nongeneralizable type variable ins : 'Y.M[0] -> unit[D;unit] uncaught exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: Fix: Test: bug1177.sml Owner: dbm Status: fixed in 109.27 ---------------------------------------------------------------------- Number: 1178 Title: Overloaded constants in patterns Keywords: Patterns, constants, type constraints, overloading Submitter: Andrew.Kennedy@persimmon.co.uk Date: 3/27/97 Version: 109.26 System: Alpha Severity: Minor Problem: Compiler bug rather than literal range error Code: fn 0w1000 : Word8.word => "a" Transcript: Error: Compiler bug: MatchComp: overflow in pattern Fix: Test: bug1178.sml Owner: jhr Status: fixed in 109.27 [dbm, 4/11/97] ---------------------------------------------------------------------- Number: 1179 Title: unmatched type specification leads to a Compiler bug error Keywords: Submitter: Elsa L. Gunter Date: 27 March 1997 Version: 109.26 System: linux, version 2.0 Severity: minor Problem: An unmatched type specification leads to a Compiler bug error. Code: structure A : sig type 'a t val f : 'a -> 'a t end = struct fun f y = [y] end; Transcript: canna% sml Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] - use "type_bug.sml"; [opening type_bug.sml] type_bug.sml:11.1-11.78 Error: unmatched type specification: t Error: Compiler bug: TypesUtil: tyvarType 124 uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 modules/sigmatch.sml:703.39 modules/sigmatch.sml:743.30 modules/sigmatch.sml:813.24 elaborate/elabmod.sml:1008.8 ... Comments: [dbm, 3/27/97] Similar to bug 1174. Fix: made TypesUtil.tyvarType do something sensible with WILDCARDty argument. Test: bug1179.sml Owner: dbm, Zhong Status: fixed in 109.28 [dbm, 4/20/97] ---------------------------------------------------------------------- Number: 1180 Title: bug in blastRead, blastWrite? Keywords: blastRead, blastWrite Submitter: Chris Paris Date: 3/20/97 Version: 109.25.2, 109.23, 109.19 System: ? Severity: major Problem: I've been using the SML/NJ blast read and write primitives to store and retrieve a complex data structure in a program I'm working on. This technique has been working fine for over a year. Recently, the program has been breaking in strange ways, and I wonder if perhaps the blast read/write primitives have not kept up with the other work on the compiler. I've not yet been successful in coming up with a short example program that demonstrates that the problem is with an SML/NJ primitive, but I thought I'd ask at this point, in case you know for sure that there's a problem. I've been having these problems with 109.25.2, 109.23, and 109.19. The problem exhibits itself slightly differently in each of those versions. I'm curious about whether anyone else is using the blast read/write primitives in their work, and also I'd like to know why these facilities were devised in the first place. Was it for a specific project? Code: Transcript: Comments: [jhr, 3/25/97] As far as I know, there is no reason that blast read/write should be broken, but it is possible. What version did it last work in? One way to test this would be to blast in a value after you blast it out, and make sure it hasn't changed. [Chris Paris, 3/25/97] To provide a little context here, our application is a single server application that provides UNIX system administration functionality for all of the machines in CMU SCS. There is a single SML process on one machine, which accepts connections from clients on the network. That's a vast oversimplification (makes it sound like a bunch of perl scripts), but at least it indicates what I'm working on. The size of the SML part of the project is a bit over 13,000 lines. We've been running our "production version" code on 109.19 for quite a while, and it has "seemed" to work. There is the occasional crash or weird behavior, which I've previously attributed to possible bugs in our SML code, or other bugs in the compiler or runtime system. Our newer code is bigger and more complex, and it fails readily on 109.19 and anything after that (it fails in a different way with each version of the compiler). (And no, I'm not trying to blastRead an object written with a different compiler.) I'm using blast read/write to store a sort of database. It gets read into memory, just once, at startup time, and periodically written out in a single blast operation. If the write/read pair were to dramatically corrupt the data, then I should expect the overall system to fail rather quickly. But if only a few things are messed up, it's conceivable that the system would give the impression that everything is okay, at least for a time. That's somewhat hard for me to believe, but the evidence suggests that that's what's happening. I can initialize my "database" from scratch by running some scripts, rather than by loading a previously blasted SML runtime value. For a few days now I've been running a system that is fully functional except that it does no blast read/write operations. We've been unable to make this one crash. The trouble is, any small test I've performed with the blast functions, such as writing out a simpler data structure that I can easily verify after reading it back, indicates that the blast functions are working fine. Until I can come up with a clear sample that causes the blast functions to fail, the best I can say is that our whole program appears to work if we don't use it and fails in subtle ways if we do use it. The obvious risk with using the blast functions is a type mismatch between the reading and the writing side, since it's completely up to the programmer to get it right. But I think if I were getting the types wrong, it would fail immediately. Besides, I have the code structured to avoid that possibility. E.g., type db = ... fun read_it () : db = ... blastRead ... fun write_it (obj : db) = ... blastWrite ... Fix: Test: Owner: jhr Status: open ---------------------------------------------------------------------- Number: 1181 Title: tmp argument naming in front end Keywords: absyn Submitter: Manual Fahndrich Date: March 29/97 Version: 109.26 System: x86/Unix Severity: low Problem: The function FUNdec in elabutil.sml introduces new temporary names for function arguments. Unfortunately, all arguments are called the same, namely "arg". This makes it extremely inconvenient to use the frontend for other compiler work, since the lexical structure is not preserved by the nameing. Code: Parse the function: - fun h x = h x You get: val g = let val g = (fn arg => (fn arg => (case (arg,arg) of (h,x) => h (x)))) in g end Printed using ppDec. The 2nd "arg" shadows the first, if one goes by identifier names. Transcript: Comments: Fix: Use numbered names. arg1, arg2, .... Test: Owner: dbm, Zhong Status: open ---------------------------------------------------------------------- Number: 1182 Title: Error: Compiler bug: PPType: printTyvar Keywords: types, printing Submitter: Lal George Date: 97/3/31 Version: 109.26 System: all Severity: minor Problem: Code: datatype t = INT of int fun f (INT n) = INT ~n Transcript: - datatype t = INT of int fun f (INT n) = INT ~n; stdIn:18.17-18.23 Error: operator and operand don't agree [tycon mismatch] operator domain: int operand: Error: Compiler bug: PPType: printTyvar Comments: Fix: Test: bug1182.sml Owner: dbm Status: fixed in 109.27 [dbm] ---------------------------------------------------------------------- Number: 1183 Title: distorted abstract syntax printed in type error message Keywords: error messages, printing, abstract syntax Submitter: Dave MacQueen Date: 4/1/97 Version: 109.27 System: - Severity: major Problem: distorted abstract syntax printed in type error message Transcript: - val (_, x) = true; stdIn:9.1-9.18 Error: pattern and expression in val dec don't agree [tycon mismatch] pattern: 'Z * 'Y expression: bool in declaration: (_,x) = (case true of (_,x) => {1=x}) Comments: Derived from 1160. Fix: Test: bug1160.sml Owner: Zhong, dbm Status: open ---------------------------------------------------------------------- Number: 1184 Title: Compiler infinite loop Keywords: Submitter: Dino Oliva oliva@cse.ogi.edu Date: 04/02/97 Version: 109.26 System: sparc-unix Severity: major Problem: When compiling this code, the compiler seems to go into an infinite loop and eventually runs out of heap and dies. I suspect it is the code generator because it compiles fine on the x86-unix platform. Code: attached below Transcript: [42] sml Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] - use "foo.sml"; [opening foo.sml] GC #0.0.0.0.1.3: (20 ms) foo.sml:139.3-139.79 Warning: value restriction prevents type variable generalization : 'Z foo.sml:139.3-139.79 Warning: value restriction prevents type variable generalization : 'Y foo.sml:163.3-163.82 Warning: value restriction prevents type variable generalization : 'X foo.sml:163.3-163.82 Warning: value restriction prevents type variable generalization : 'W foo.sml:202.9-203.47 Warning: value restriction prevents type variable generalization : 'V foo.sml:237.9-237.61 Warning: value restriction prevents type variable generalization : 'U foo.sml:237.9-237.61 Warning: value restriction prevents type variable generalization : 'T foo.sml:237.9-237.61 Warning: value restriction prevents type variable generalization : 'S foo.sml:238.9-238.60 Warning: value restriction prevents type variable generalization : 'R foo.sml:240.9-240.69 Warning: value restriction prevents type variable generalization : 'Q foo.sml:240.9-240.69 Warning: value restriction prevents type variable generalization : 'P foo.sml:241.9-241.54 Warning: value restriction prevents type variable generalization : 'O GC #0.0.0.0.2.41: (100 ms) ... [lots of gc's] ... /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 97124352 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size GC #10.141.142.144.150.3024: (21570 ms) /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284360704 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size GC #11.142.143.145.151.3044: (21550 ms) /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284557312 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size GC #12.143.144.146.152.3064: (21630 ms) /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284753920 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size GC #13.144.145.147.153.3084: (22140 ms) /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 284950528 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to allocate to-space for generation 5; trying smaller size /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Error -- unable to map 86441984 bytes, errno = 12 /projects/pacsoft/tools/smlnj-1.09.26/bin/.run/run.sparc-sunos: Fatal error -- unable to allocate minimum size [43] Comments: I've cut down the problem from a couple thousand lines of code across several modules to the 250 lines here. Taking out much more makes the problem go away. In the MilC structure, changing either the definition of eqmember or map2 to the (trivial) commented out versions is sufficient to get the compiler to terminate. Unfortunately, these definitions are not quite what I need. [Zhong, 4/3/97] Somehow the closure phase is generating this 16-arguments function (which goes beyond the register limits, thus the infinite loop). Fix: Test: bug1184.sml Owner: Zhong Status: fixed in 109.27 [Zhong] ---------------------------------------------------------------------- Number: 1185 Title: Compiler bug of DECON on data constructors Keywords: datatypes, dataconstructors Submitter: Zhong Shao (shao@cs.yale.edu) Date: April 4, 1997 Version: 109.26 System: sparc Severity: medium Problem: Compiler bug of DECON on data constructors Code: structure A = struct datatype context = NoContext | Local of unit fun pp_context (Local a1) = () | pp_context _ = () end Transcript: daffy% xrun sml.sparc Standard ML of New Jersey, Version 109.26, March 25, 1997 [new runtime] - use "zbug.sml"; [opening zbug.sml] Error: Compiler bug: Wrapping: DECON on a constant or exnconst data constructor uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 util/stats.sml:164.40 util/stats.sml:164.40 util/stats.sml:164.40 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 - Comments: unit-carrying data constructors are mis-treated as constant constructors. Fix: Test: bug1185.sml Owner: Zhong Status: fixed in 109.27 ---------------------------------------------------------------------- Number: 1186 Title: type printing in multi-declaration Keywords: types, printing Submitter: Dave MacQueen Date: 4/7/97 Version: 109.26.1 System: - Severity: minor Problem: If a type constructor and a value whose type mentions the type constructor are defined in a single top-level declaration, the name of the type constructor is printed with "?.". Code: datatype t = A val x = A; Transcript: - datatype t = A val x = A; = datatype t = A val x = A : ?.t - Comments: Fix: Test: bug1186.sml Owner: dbm Status: open ---------------------------------------------------------------------- Number: 1187 Title: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE Keywords: translate Submitter: Lal George Date: 4/8/97 Version: 109.26.1 System: - Severity: major Problem: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE Code: bug521.sml Transcript: Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled] - use "bug521.sml"; [opening bug521.sml] Error: Compiler bug: Translate: unexpected tyvar LBOUND in mkPE uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 translate/translate.sml:129.39 translate/translate.sml:129.39 util/stats.sml:164.40 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: found in regression testing [Zhong, 4/8/97] This error message is complaining about a type variable that is not generalized anywhere. This could be caused by placing the wrong value into the "boundtvs" field in the VALdec (VB {...}) in absyn (during typechecking). The code above shows that it might be related to the tyvar of "flex-record", i.e., the type for variable "a" above. Fix: Test: bug521.sml Owner: dbm, Zhong Status: fixed in 109.27 [dbm, 4/9/97] ---------------------------------------------------------------------- Number: 1188 Title: Compiler bug: Unify: instTyvar Keywords: type checking, instTyvar Submitter: Carlos Puchol (cpg@cs.utexas.edu) Date: 4/8/97 Version: 109.26.1 System: - Severity: major Problem: Type error causes "Compiler bug: Unify: instTyvar" Code: datatype K = A of int | B of {one:int, two:string}; val b = B {one = 1, two="TWO"}; #two b; Transcript: Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [new runtime] - datatype K = A of int | B of {one:int, two:string}; datatype K = A of int | B of {one:int, two:string} - val b = B {one = 1, two="TWO"}; val b = B {one=1,two="TWO"} : K - #two b; Error: Compiler bug: Unify: instTyvar: OPEN/FLEX not instantiated to record type Comments: [Lal, 4/8/97] This bug is also exhibited in bug1049. For this test case there used to be a fairly nice error message. :::::::::::::::::::::::::::::bug1049.sml:::::::::::::::::::::::::: (* bug1049.sml *) fun f x = (map real (#1 x); map op o x); ---------------------------bad--------------------------- val it = () : unit Error: Compiler bug: Unify: instTyvar: OPEN/FLEX not instantiated to record type ---------------------------outputs----------------------- val it = () : unit bug1049.sml:3.11-3.40 Error: operator and operand don't agree (type mismatch) operator domain: (('Z -> 'Y) * ('X -> 'Z)) list operand: {1:int list, '...W} in expression: map o x bug1049.sml:3.1-3.40 Error: unresolved flex record (can't tell what fields there are besides #1) Fix: Test: bug1188.sml Owner: dbm Status: fixed in 109.27 ---------------------------------------------------------------------- Number: 1189 Title: Opening Real crashes system Keywords: Real, overflow, open Submitter: Jeff Foster, jfoster@cs.berkeley.edu Date: 4/9/97 Version: 109.26 System: hpux Severity: minor Problem: typing ``open Real;'' at the prompt causes ML to raise an exception and makes the system unusable without restarting Code: open Real; Transcript: Standard ML of New Jersey, Version 109.26, March 25, 1997 [CM; autoload enabled] - 3+4; val it = 7 : int - open Real; open Real structure Math : MATH val radix = 2 : int val precision = 52 : int val maxFinite = 1.79769313486e308 : real uncaught exception in compiler: overflow raised at: print/ppobj.sml:397.20 print/ppobj.sml:397.20 print/ppobj.sml:397.20 util/pp.sml:545.6 build/evalloop.sml:191.58 - 3+4; uncaught exception in compiler: overflow raised at: util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:191.58 Comments: Fix: Test: bug1189.sml Owner: Lal? Status: fixed in 109.27 [Lal, 4/11/97] ---------------------------------------------------------------------- Number: 1190 Title: Exception values matching against exceptions in signatures Keywords: Modules Exceptions "IO", "reals"> Submitter: Andrew.Kennedy@persimmon.co.uk Date: 4/11/97 Version: 109.26 System: Alpha Severity: Minor Problem: The code should fail to elaborate Code: structure STR :> sig exception E end = struct val E = Overflow end Transcript: Error: Compiler bug: SigMatch:matchVElem.2 Comments: None Fix: Test: bug1190.sml Owner: dbm Status: fixed in 109.27 [dbm, 4/16/97] ---------------------------------------------------------------------- Number: 1191 Title: pattern matching in presence of datatype replication Keywords: datatype replication, pattern matching Submitter: Tore Jahn Bastiansen Date: 4/15/97 Version: 109.26 System: - Severity: major Problem: Match compiler is not properly handling a match over constructor(s) imported into a structure via a datatype replication declaration. Code: structure S = struct datatype d = D | E (* d must have more than one constructor *) and h = H of d end; structure A = struct datatype h = datatype S.h end fun f (S.H x) = true; fun g (A.H x) = true | g _ = false; fun g1 (A.H x) = true; fun h (A.H x) = true | h (S.H x) = false; val a = S.H(S.D); val b = A.H(S.D); val f_a = f a; val g_a = g a; val h_a = h a; val f_b = f b; val g_b = g b; val h_b = h b; val g1_a = g1 a; Transcript: - use "bug1191.sml"; [opening bug1191.sml] structure S : sig datatype d = D | E datatype h = H of d end structure A : sig datatype h = H of ?.d end val f = fn : S.h -> bool val g = fn : S.h -> bool <-- should yield redundant match warning bug1191.sml: Warning: match nonexhaustive <-- bogus! H x => ... val g1 = fn : S.h -> bool bug1191.sml: Warning: match redundant <-- expected H x => ... --> H x => ... val h = fn : S.h -> bool val a = H D : S.h val b = H D : S.h val f_a = true : bool val g_a = false : bool <-- bogus! val h_a = true : bool val f_b = true : bool val g_b = false : bool <-- bogus! val h_b = true : bool val it = () : unit uncaught exception TopLevelException [nonexhaustive match failure] raised at: bug1191.sml:14.18 <-- compiling g1 a Comments: Fix: Test: bug1191.sml Owner: dbm Status: fixed in 109.27 ---------------------------------------------------------------------- Number: 1192 Title: datatype replication not implemented inside of expressions Keywords: datatype replication Submitter: Dave MacQueen Date: 4/15/97 Version: 109.26.1 System: - Severity: major Problem: In elabcore, function elabDec', the case for DatatypeDec does not deal with datatype replication. Code: datatype d = D; let datatype t = datatype d in () end; Transcript: - datatype d = D; datatype d = D - let datatype t = datatype d in () end; uncaught exception in compiler: nonexhaustive match failure raised at: elaborate/elabtype.sml:234.43 elaborate/elabcore.sml:549.36 elaborate/elabcore.sml:549.36 elaborate/elabcore.sml:549.36 ... Comments: Fix: add the missing case Test: bug1192.sml Owner: dbm Status: fixed in 109.27 [dbm, 4/16/97] ---------------------------------------------------------------------- Number: 1193 Title: Memory leak due to ref cells Keywords: ref cells, dereferencing, memory leak Submitter: Chris Stone, cstone+@cs.cmu.edu Edo Biagioni, esb+@cs.cmu.edu Date: 4/15/97 Version: 109.25.2, 109.26 System: alpha-osf1v3.2c Severity: major Problem: A loop which should run in constant space causes the virtual storage required by the program to grow with no apparent bound. Code: structure Leak = struct local type T = {field: unit} val data = {field = ()} fun monitor n = if (n mod 10000 = 1) then (print "starting garbage collection..."; SMLofNJ.Internals.GC.doGC 0; SMLofNJ.Internals.GC.doGC 0; print " done\n") else () val handlers = ref ((fn _ => ()): T -> unit) in fun run n : unit = (handlers := ! handlers; (* comment this line out for no leak *) (! handlers) data; (* comment this line out for much faster leak *) monitor n; run (n + 1)) end end Transcript: Leak.run 0; Comments: We measured virtual memory size by using the following shell script, which records the size of the ML process at approximately 5-second intervals. (It assumes there is only one such process running on the machine). #! /bin/csh -f set f = ./sizes touch $f while (1) set x = `ps auxwww | fgrep run | fgrep -v grep | awk '{print $5}' | tr MK ' ' | sort -n -r | head -1` echo $x echo $x >> $f sleep 5 end The leak should start to become visible within several minutes. The rate of increase slows somewhat as time passes, but the space usage does not appear to level off. The code does double garbage collections because John Reppy indicated this as a workaround for a previously-reported memory leak (having to do with array allocation). In tests with a more complicated piece of code from which the above was derived, changing the type T (to unit, for example) caused the space leak to vanish. A hypothesis consistent with the facts is that handlers := ! handlers; adds some sort of boxing/unboxing wrapper to the function stored in the ref cell. This would explain why omitting the application of this function causes the program (and the leak) to go significantly faster and why removing the assignment or changing the type T could fix the leak. Comment: [Lorenz, 5/20/97] The memory leak in the presence of function refs seems to have been properly diagnosed by its submitter; i.e. wrapper records are being continually chained around the ref's value. The following source and cps (for f) illustrates: bug: type T = int*int val handlers = ref ((fn _ => ()): T -> unit); fun f _ : unit = (handlers := !handlers; f ()); ****starting genfrag KNOWNCHK **** v696(v741[I],v740[PV]) = !(v740) -> v625[F] {RK_ESCAPE 2,(L)v697,v625} -> v698 boxedupdate(v740,(I)0,v698) !(v740) -> v670[F] {RK_ESCAPE 2,(L)v705,v670} -> v706 boxedupdate(v740,(I)0,v706) !(v740) -> v674[F] {RK_ESCAPE 2,(L)v713,v674} -> v714 boxedupdate(v740,(I)0,v714) !(v740) -> v678[F] {RK_ESCAPE 2,(L)v721,v678} -> v722 boxedupdate(v740,(I)0,v722) (L)v696((I)0,v740) (* wrapper functions deleted *) nobug: type T = int; val handlers = ref ((fn _ => ()): T -> unit); fun f _ : unit = (handlers := !handlers; f ()); ****starting genfrag KNOWNCHK **** v946(v959[I],v958[PV]) = !(v958) -> v888[F] boxedupdate(v958,(I)0,v888) !(v958) -> v929[F] boxedupdate(v958,(I)0,v929) !(v958) -> v930[F] boxedupdate(v958,(I)0,v930) !(v958) -> v931[F] boxedupdate(v958,(I)0,v931) (L)v946((I)0,v958) [Zhong, 5/21/97] Thanks for diagnosing it for me, Lorenz. I didn't read the comments section of their bug report. Yes, when we do "handlers := !handlers", a pair of wrap and unwrap operations are inserted, they should ultimately cancel out from each other, but occasionally, the eta-reduction code in cpsopt leave some eta-redexes un-reduced --- causing a trivial closure being built each time. Your above code actually works ok in pre-109.28 (because of more aggressive front-end optimizations), though the code in the original bug report still does not work quite right. I'll look into it and fix it in 109.28. [Zhong, 8/15/97] I modified the CPS optimizer to be more aggressive on reducing the eta redex. This fixes the bug 1193 --- but ideally, I should do a fix that can guaranttee the following: For any ref cell x of type "\tau ref", the expression "x := !x" should not introduce extra heap allocations. The new CPS optimizer will handle most of type \tau, but I can't prove that it can make such guaranttee. I have some idea how the "ideal" fix should be like. For the time being, I'd suggest that we add the above comments to bug 1193, still leave it as open, but down-grade its priority to Medium. Fix: * Test: * Owner: Zhong Status: open ---------------------------------------------------------------------- Number: 1194 Title: Compiler bug: TypesUtil: extractDcons Keywords: datatype replication, error message Submitter: Vladimir Gapeyev Date: 04/16/97 Version: 109-26, 109-26.1 System: Solaris Severity: moderate? Problem: Attempt to replicate a datatype from a structure which is a functor argument, generates CompilerBug. Code: signature FOO = sig type 'a t end functor Make (structure Foo : FOO) = struct datatype p = datatype Foo.t end Transcript: use "bug.sml"; [opening bug.sml] Error: Compiler bug: TypesUtil: extractDcons uncaught exception Error raised at: util/errormsg.sml:51.14-51.19 elaborate/elabmod.sml:1231.7 elaborate/elabmod.sml:1112.33 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: [dbm, 4/16/97] This particular code would not work because the type t in the signature FOO is not specified as a datatype, but a proper error message should be generated. Fix: check that rhs is datatype in elabmod and elabsig. Test: bug1194.sml Owner: dbm Status: fixed in 109.28 [dbm, 4/20/97] ---------------------------------------------------------------------- Number: 1195 Title: wrong unit type for CharVector.app Keywords: signature matching Submitter: Elsa L. Gunter, elsa@research.bell-labs.com Date: 4/17/1997 Version: 109.26.1 System: Pentium Pro 200-linux2.0 Severity: minor Problem: The type of CharVector.app doesn't match elem -> unit -> vector -> unit because unit and General.unit aren't recognized as the same. Code: structure A : sig eqtype vector type elem val app : elem -> unit -> vector -> unit end = CharVector; Transcript: Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled] - structure A : sig eqtype vector type elem val app : elem -> unit -> vector -> unit end = CharVector; stdIn:17.1-22.19 Error: value type in structure doesn't match signature spec name: app spec: ?.CharVector.elem -> ?.unit -> ?.CharVector.vector -> ?.unit actual: (?.CharVector.elem -> ?.General.unit) -> ?.CharVector.vector -> ?.General.unit - Comments: If I replace app by appi then the problem goes away. Standard ML of New Jersey, Version 109.26.1, April 2, 1997 [CM; autoload enabled] - structure A : sig eqtype vector type elem val appi : (int * elem -> unit) -> vector * int * int option -> unit end = CharVector; structure A : sig type vector = string type elem = char val appi : (int * elem -> unit) -> vector * int * int option -> unit end Fix: Test: bug1195.sml Owner: jhr, erg Status: not a bug ---------------------------------------------------------------------- Number: 1196 Title: discrepencies between Basis implementation and documentation Keywords: Basis Submitter: Elsa Gunter Date: 4/17/97 Version: 109.26.1 System: - Severity: major Problem: The following is a list of things missing from sml-nj.109.26.1 which the standard basis requires. The structure General is missing: type ref exception Chr The structure Char is missing: type string val fromCString : string -> char option val toCString : char -> string The structure StringCvt has the wrong datatype declaration for realfmt. It should be: datatype realfmt = SCI of int option | FIX of int option | GEN of int option | EXACT The structure String is missing: structure Char : CHAR val extract : (string * int * int option) -> string val map : (Char.char -> Char.char) -> string -> string val fromCString : string -> string option val toCString :string -> string The structure Substring is missing: structure String : STRING val extract : (string * int * int option) -> substring val join : substring * substring -> substring The structure Vector is missing: val mapi : (int * 'a -> 'b) -> 'a vector * int * int option -> 'b vector val map : ('a -> 'b) -> 'a vector -> 'b vector The structure CharVector is missing: val mapi : (int * elem -> elem) -> vector * int * int option -> vector val map : (elem -> elem) -> vector -> vector The structure TextIO is missing: val scanStream : ((Char.char,StreamIO.instream)StringCvt.reader -> ('a,StreamIO.instream)StringCvt.reader) -> instream -> 'a option Comments: Fix: Test: Owner: jhr, erg Status: fixed in 109.31 ---------------------------------------------------------------------- Number: 1197 Title: type sharing not propagated Keywords: modules, functors, opaque constraints, type sharing Submitter: Bob Harper Date: 4/18/97 Version: 109.25.1 System: - Severity: major Problem: 1. Type sharing is not propagated. If I instantiate Interp with a structure AbSyn, then invoke Interp.evaluate on something from AbSyn, I get a type error in the second case, but not the first. The problem remains if I extend the "where type" list to stipulate equality of all types in the signature. 2. When instantiating Interp in the second form, I get: - structure Interp = Interp (structure A = AbSyn); *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11] *** Warning for compiler writers: PATHtyc bind. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.12] *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11] *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11] *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11] *** Warning for compiler writers: PATHtyc decl. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.11] *** Warning for compiler writers: PATHtyc expr. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.8] *** Warning for compiler writers: PATHtyc expr. in translate: [#Gc5e.2,#Gc5e.1,#Gfbc.8] structure Interp : sig structure AbSyn : val evaluate : AbSyn.expr -> AbSyn.expr end 3. We desperately need a structure analogue of where type! I'd like to write INTERP where AbSyn = A rather than write out all the type patching. Code: bug1197.sml Transcript: Standard ML of New Jersey, Version 109.25.1, February 26, 1997 [CM; autoload enabled] - use "test/src/t98.sml"; [opening test/src/t98.sml] signature ABSYN = sig datatype expr = Int of int end signature INTERP = sig structure AbSyn : sig datatype expr = Int of int end val evaluate : AbSyn.expr -> AbSyn.expr end functor Interp : structure Absyn : ABSYN *** Warning for compiler writers: PATHtyc expr. in translate: [#G47a.2,#G47a.1,#Gd47.2] *** Warning for compiler writers: PATHtyc expr. in translate: [#G47a.2,#G47a.1,#Gd47.2] structure E : sig structure AbSyn : val evaluate : AbSyn.expr -> AbSyn.expr end test/src/t98.sml:27.1-27.32 Error: operator and operand don't agree (tycon mismatch) operator domain: expr operand: Absyn.expr in expression: E.evaluate (Int (3 : int)) uncaught exception exception Error raised at: build/evalloop.sml:103.44-103.52 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:273.46-273.49 - Comments: Fix: Test: bug1197.sml Owner: dbm Status: fixed in 109.26.1 ---------------------------------------------------------------------- Number: 1198 Title: unnecessary "?." in printed type name Keywords: types, printing Submitter: Allen Stoughton Date: 4/18/98 Version: 109.27 System: - Severity: major Problem: The type of a value exported from an abstype is printed with a "?". Code: abstype foo = A with val x = A end; Transcript: Standard ML of New Jersey, Version 109.26, March 25, 1997 - abstype foo = A with val x = A end; type foo val x = - : ?.foo But x had type foo in 109.25: Standard ML of New Jersey, Version 109.25, February 1, 1997 - abstype foo = A with val x = A end; type foo val x = - : foo Comments: printed ok in 109.25 Fix: call of trueValType for printing variable types was removed somewhere after 109.25. I restored the call of trueValType inside of ppVal. Test: bug1198.sml Owner: dbm Status: fixed in 109.28 [dbm, 4/30/97] ---------------------------------------------------------------------- Number: 1199 Title: size of exportFn image Keywords: exportFn, image size Submitter: Nikolaj Bjorner Date: 5/2/97 Version: 109.27 System: - Severity: major Problem: exportFn image sizes have grown since 108. Code: (* 108: *) structure Test = struct fun dummy(_,[name]) = (print ("Hi I am "^name^"\n")) fun export() = exportFn("/step/sml-108/bin/.heap/hi",dummy) end (* 109.27 *) structure Test = struct fun dummy(name,_) = (TextIO.print ("Hi I am "^name^"\n"); OS.Process.success) fun export() = SMLofNJ.exportFn("/step/sml/bin/.heap/hi",dummy) end Comments: The sizes of the exported images were: 108: -rw-rw---- 1 nikolaj 196292 May 1 22:42 hi 109.27 -rw-rw---- 1 nikolaj 500824 May 1 22:38 hi.sparc-solaris For larger executables the situation gets even worse. I reported an image size of more than 35 MB in 109.27 compared to approx 13 MB in 108. [Zhong, 5/2/97] This difference seems to be caused from changes in the runtime system, as even the image for a null function is about this big. fun export1() = SMLofNJ.exportFn("xxx1", dummy); fun export2() = SMLofNJ.exportFn("xxx2", fn _ => 0); -rw-r--r-- 1 shao systems 449616 May 2 09:38 xxx1.sparc-solaris -rw-r--r-- 1 shao systems 433232 May 2 10:55 xxx2.sparc-solaris I also checked the runtime closures for both the dummy function and the "fn _ => 0" function, they all contain minimum amount of free variables. |> For larger executables the situation gets even worse. I |> reported an image size of more than 35 MB in 109.27 compared |> to approx 13 MB in 108. |> |> Is there any way to improve on this situation? This could be caused by completely different reasons from the previous. Sorry for keeping asking this, but if you can ship us the entire source code, we can probably take a look and narrow the problem down for you. Fix: Test: Owner: jhr Status: fixed in 109.31 [jhr, Zhong, 9/15/97] ---------------------------------------------------------------------- Number: 1200 Title: where type problem, rhs within current signature Keywords: modules, signatures, where type Submitter: Robert Findler Date: 5/4/97 Version: ? System: - Severity: major Problem: A functor using a definitional type spec in the parameter signature works, while an equivalent version using "where type" fails with uncaught exception Unbound. Code: signature S = sig type t end; functor F1(structure X : S structure Y : sig type t = X.t end) = struct val x = 1 end; functor F2(structure X : S structure Y : S where type t = X.t) = struct val x = 1 end; Transcript: - use "test/bugs/bug1200.sml"; [opening test/bugs/bug1200.sml] signature S = sig type t end functor F1 : uncaught exception Unbound raised at: elaborate/elabmod.sml:1143.39-1143.49 util/stats.sml:164.40 build/evalloop.sml:120.38 build/evalloop.sml:191.58 build/evalloop.sml:283.46-283.49 Comments: Fix: In finalize in explore_tclass, when there is an "external" (i.e. where clause) definition, characterize it as NINST instead of INST, and remove the call to simplify (so that instToTyc will deal with it properly. Test: bug1200.sml, bug1201.sml Owner: dbm Status: fixed in 109.28 [dbm, 5/18/97]