Number: 601 Title: bad implementation of Assembly.A.logb Keywords: arithmetic, Assembly Submitter: John Reppy (jhr@research.att.com) Date: 7/29/92 Version: 0.75-0.85 (probably earlier versions too) System: SPARC Severity: minor Problem: The implementation of logb in runtime/SPARC.prim.s doesn't work for 0.0 Code: (System.Unsafe.Assembly.A.logb 0.0) Transcript: Standard ML of New Jersey, Version 0.86, July 22, 1992 val it = () : unit - (System.Unsafe.Assembly.A.logb 0.0); val it = uncaught exception Boxity Fix: "beq 1f" should be "beq 2f" Status: fixed in 0.87 ---------------------------------------------------------------------- Number: 602 Title: uncaught exception UnboundTable using System.Env.describe Keywords: environment, describe Submitter: Dave MacQueen Date: 9/29/92 Version: 0.85 Severity: major Problem: Invoking System.Env.describe on topLevelEnv with structure symbol "System" yields uncaught exception UnboundTable Transcript: Standard ML of New Jersey, Version 0.85, July 17, 1992 val it = () : unit - System.Env.describe (System.Env.staticPart (!System.Env.topLevelEnvRef)) (System.Symbol.strSymbol "System"); uncaught exception UnboundTable - Comment: System is in Pervasives, not topLevelEnv, but describe should catch the exception and give a report. Status: fixed in 0.89 (Cregut) ---------------------------------------------------------------------- Number: 603 Title: System.Symbol.makestring gives erroneous answer Keywords: makestring Submitter: cregut Date: 7/29/92 Version: .83 -> .86 System: all Severity: minor Problem: System.Symbol.makestring gives erroneous answer Code: Transcript: - open System.Symbol; open Symbol - makestring(sigSymbol "s"); val it = "TYC$s" : string Comments: bad order of namespaces Fix: change makestring in env.sml Test File: let open System.Symbol in if (makestring(valSymbol "s")^makestring(tycSymbol "s")^ makestring(sigSymbol "s")^makestring(strSymbol "s")^ makestring(fctSymbol "s")^makestring(fixSymbol "s")) = "VAL$sTYC$sSIG$sSTR$sFCT$sFIX$s" then "System.Symbol.makestring seems O.K." else "Verify the behaviour of System.Symbol.makestring" handle _ => "System.Symbol.makestring has a major bug" end Status: fixed in 0.87 ---------------------------------------------------------------------- Number: 604 Title: blast_read/blast_write broken Keywords: I/O, blast_read, blast_write Submitter: Emden R. Gansner erg@ulysses.att.com Date: 7/30/92 Version: 0.86 System: Sparc 2, SunOS 4.1 Severity: major Problem: blast_read/blast_write is broken Code: (* The following function writes a value, then reads it back in * and compares them. In 0.86, the values are not equal. * If one attempts to print v', the system hangs, causing a * core dump on interrupt. * You can replace 'int list' with your favorite eqtype *) fun btest v = let val ofd = open_out "dump" val bwrite : outstream * int list -> int = System.Unsafe.blast_write val bread : instream * int -> int list = System.Unsafe.blast_read val sz = bwrite(ofd,v) val _ = close_out ofd val ifd = open_in "dump" val v' = bread(ifd,sz) in close_in ifd; if v = v' then print "v = v'\n" else print "print v <> v'\n" end Transcript: Standard ML of New Jersey, Version 0.86, July 22, 1992 val it = () : unit - use "btest.sml"; val btest = fn : int list -> unit [closing btest.sml] val it = () : unit - btest []; [Major collection...abandoned] print v <> v' val it = () : unit - btest [1,2]; [Major collection...abandoned] print v <> v' val it = () : unit - Comments: Does this have anything to do with bug 548 being fixed? Fix: [Appel] at the beginning of ml_blast_out in cfuns.c, insert the following line after "blast_fd = REC_SEL..." msp->ml_arg = arg; Then do a makeml -noclean and things ought to work better. Status: fixed in 0.87 ---------------------------------------------------------------------- Number: 605 Title: whose bug? Keywords: Submitter: Charles Krasic cckrasic@plg.waterloo.edu Date: 7/31/92 Version: 0.75 System: Sparc, SunOS 4.1.2 Severity: critical Problem: file compiles OK with batch compiler, but runtime/run fails with "uncaught exception (Loader): Syntax" Comments: I am working on the source code of NJSML itself. I have made some fairly significant changes so it would be a non-trivial amount of work for me to give you all the code necessary to run NJSML and reproduce my problem. I have isolated my problem to 1 line of code in the source code which is will briefly summarize here. The file that contains the code in question is at the end of this message. This code is part of my modified type checker. Roughly, it is called prior to the 0.75 typechecker (there are many changes...) This seems to be a very nasty bug to me. It should be noted that, while I am changing the compiler, I am compiling my changed version with the stock 0.75 version of the batch compiler. My changes are confined entirely to the front end of the compiler (nothing after typechecking). Some of the things I tried: The offending section of code is: 1. (case var of 2. (VALvar{constraints,...}) => 3. (ConstraintsStack.push constraints; 4. constructList := (constraints :: (!constructList)); 5. expType(env,exp,err,loc); 6. ConstraintsStack.pop()) 7. | _ => (ErrorMsg.impossible "MakeImplicitsPass.Pass2.valrecType")) If lines 3,4 and 6 are removed (and 5 has the semicolon removed), it will build OK. Alternatively, if line 5 is removed, it also will build OK. Of course, either of those things doesn't do what I want it to do. I have tried many variations on the above code but could not get any to work. Status: not a bug (bug was in his own code) ---------------------------------------------------------------------- Number: 606 Title: Allocating space for saved FP registers is awkward Keywords: floating point, registers Submitter: Mark Leone (mleone@cs.cmu.edu) Date: 7/31/92 Version: 0.82 System: i386 Severity: Necessary change for i386 runtime Problem: Allocating space for saved FP registers is awkward Code: none Transcript: none Comments: In runtime/signal.c, in make_ml_sigh_arg(), floating point registers are saved as follows: #if (NSAVED_FPREGS > 0) savefpregs (msp); fpregs = PTR_CtoML(msp->ml_allocptr + sizeof(long)); msp->ml_allocptr += (NSAVED_FPREGS*2 + 1) * sizeof(long); #else ... This code assumes that savefpregs only needs NSAVED_FPREGS*2 + 1 words. This assumption fails on the 386, since the entire FP coprocessor state must be saved, not just the registers. Fix: A better approach is for savefpregs() to update the allocptr itself and return a pointer to the saved state: #if (NSAVED_FPREGS > 0) fpregs = savefpregs (msp); #else ... Comment: [jhr] A better fix might be introducing a machine dependent constant for the fp-save area size. Also, savefpregs should probably get the save area pointer as its argument, since this would simplify the assembly code a bit. Status: obsolete ---------------------------------------------------------------------- Number: 607 Title: weak typing Keywords: types, type checking, weak types Submitter: John Greiner Date: 8/4/92 Version: 0.86 Severity: major Problem: Weak typing error allows failure of type security. Transcript: - fn x => let val a = ref nil in (let val b = a in b := [true]; hd (!b) + 1; (fn z => z) end) () end; val it = fn : 'a -> unit Fix: This can be fixed by replacing "absd-abs" by "max(0,absd-abs)" in basics/typesutil.sml. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 608 Title: minor error in runtime Keywords: runtime, cfuns Submitter: David Tarditi Date: 8/4/92 Version: 0.85 Severity: minor Problem: In version 0.85, line 114: run.c, there's a function call of the form: init_externlist(msp) but you'll see in cfuns.c that init_externlist takes no arguments. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 609 Title: include syntax Keywords: syntax, include Submitter: Larry Paulson Date: 7/31/92 Version: 0.75 Severity: minor Problem: Standard ML of New Jersey, Version 75, seems to reject the syntax include SIGID1 ... SIGIDn (See the definition of Standard ML, page 13.) Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 610 Title: changeLvars broken Keywords: lambda Submitter: Gene Rollins Date: 8/5/92 Version: 0.87 Severity: major (for separate compilation) Problem: There is a compiler bug in SML/NJ 0.85 and 0.87 that is not present in 0.80. I tracked it down to this: the function changeLvars when applied to a staticUnit sometimes eliminates bindings to fixity symbols. So, if you try to read a compiled binary file, and then compile a file that uses symbols defined in the binary file, you sometimes get an error such as this: a.sig:1.15-1.19 Error: FIRST undefined (parser) If the symbol is really undefined you also get this message: a.sig:1.15-1.19 Error: unbound signature: FIRST This happens on pmax_mach and sun4_mach machines. I found that once you have a binary file that this bug happens with, it is repeatable. But, not all binary files tickle this bug. Transcript: - System.system "cat first.sig"; signature FIRST = sig val x:int end - val perv = !System.Env.pervasiveEnvRef; val perv = prim? : environment - val se = System.Env.staticPart perv; val se = prim? : staticEnv - val (staticUnit, codeUnit) = SepComp.compileSource ("first.sig", se); [closing first.sig] val staticUnit = {boundLvars=[],staticEnv=prim?} : System.Compile.staticUnit val codeUnit = prim? : codeUnit - val delta = System.Compile.execute ((staticUnit, codeUnit), perv); signature FIRST val delta = prim? : environment - appSE (findName "FIRST") delta; (* catalogEnv; filter for symbols "FIRST" *) FIRST fixity information of a module component FIRST signature val it = () : unit - val staticUnit2 = System.Compile.changeLvars staticUnit; val staticUnit2 = {boundLvars=[],staticEnv=prim?} : System.Compile.staticUnit - val delta2 = System.Compile.execute ((staticUnit2, codeUnit), perv); signature FIRST val delta2 = prim? : environment - appSE (findName "FIRST") delta2; FIRST signature val it = () : unit - Fix: adjust for new representation of fixity bindings? Status: fixed in 0.91 (dbm) ---------------------------------------------------------------------- Number: 611 Title: batch compiler doesn't like local structure declarations Keywords: modules, syntax, local Submitter: Mark Leone (mleone@cs.cmu.edu) Date: 8/5/92 Version: 0.82 System: all Severity: very minor Problem: batch compiler doesn't like local structure declarations Code: (* From bug report #278 *) local structure Internal = struct val x=1 val y=2 end in structure First : sig val x : int end = Internal structure Second : sig val y : int end = Internal end Transcript: Standard ML of New Jersey, Version 82, June 1, 1992 (batch compiler) [Compiling tmp.sml] Error: signature, functor, or structure expected [closing tmp.sml] Comments: This seems to be the same problem exhibited by the interactive top-level in bug report #278 (which has been fixed). Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 612 Title: bad lambda depth calculated in type checker Keywords: type checking Submitter: Mark Lillbridge (mdl@cs.cmu.edu) Date: 8/5/92 Version: 0.87 System: Sparc Severity: major Problem: Lambda depth is miscalculated in some cases causing the compiler to core dump Code: fun id x = x; (fn y => id (let val u = y in u end)) 1 2; Transcript: - fun id x = x; val id = fn : 'a -> 'a - (fn y => id (let val u = y in u end)) 1 2; Bus error (core dumped) Comments: The code in typesutil.sml that calculates lamdepth is wrong. In cases like this, lamdepth can actually decrease instead of being monotonically increasing. (Here, lamdepth is 1 at the fn y => but 0 at the let.) Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 613 Title: Compiler bug message on occurence of typevar in signature Keywords: modules, signatures, type variables Submitter: Kees van Schaik Date: 8/7/92 Version: Version 75 System: Sun 4 Sparc station running SunOS Release 4.1.1 Severity: minor Problem: Compiler bug message on occurence of typevar in signature Code: signature BuggySignature = sig exception IllegalException of '_a ref end Transcript: Standard ML of New Jersey, Version 75, November 11, 1991 The Edinburgh SML Library Make is now pre-loaded. val it = () : unit - signature BuggySignature = sig exception IllegalException of '_a ref end; signature BuggySignature = sig exception IllegalException of Error: Compiler bug: domain Comments: The signature is not a legal one since it is not allowed to use type variables in exception declarations in signatures. A somewhat more informative way of telling that would be nice (mostly to people who did not know/realise that their code was not legal when triggering the bug, who will most probably the only ones triggering it), but the bug does not cause any serious problems. Comments: [dbm] Now generates an error message when signature is elaborated. Status: fixed in 0.91 (dbm) ---------------------------------------------------------------------- Number: 614 Title: high-order-functor thinning-in Keywords: modules, functors, signature matching, thinning Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 8/6/92 Version: 0.86 System: mipsb/riscos Severity: critical Problem: high-order-functor thinning-in Code: signature SIG = sig val e : real end funsig PROD (structure M : SIG structure N : SIG) = SIG structure S = struct val e = 100.0 end structure P = struct val e = 0.0 end functor Square(structure X : SIG functor Prod : PROD) : SIG = Prod(structure M = S structure N = X) functor F(structure N : SIG) = struct val e = (N.e * N.e) end structure A = Square(structure X = P functor Prod = F); A.e; Transcript: ..................... - A.e; val it = 10000.0 : real Comments: A.e should be 0.0 instead. The problem is that when F is applied to (structure M=S structure N=P) in the body of functor Square, the argument is not thinned against the parameter signature of the functor F. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 615 Title: System.Symbol.makestring has incomplete implementation Keywords: makestring Submitter: Andrew Tolmach (apt@research.att.com) Date: 8/10/92 Version: 0.85 through 0.88 System: mips riscos Severity: minor Problem: Can't apply System.Symbol.makestring to pervasive environment. Code: - let open System.Env System.Symbol in map makestring (catalogEnv (staticPart(!pervasiveEnvRef))) end; Transcript: above code causes Compiler bug: Symbol.makestring Fix: Add TABspace case to Env.symbolToString (?) Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 616 Title: overloading versus user-bound type variable Keywords: types, overloading, type variables Submitter: Lars Birkedal Date: 8/12/92 Version: 0.87 (and earlier) Severity: minor Problem: I assume you resolve arithmetic overloading in NJSml by binding the operators, such as +, to a generel type-scheme, such as \forall 'a. 'a *'a -> 'a, where the type-variables are marked as overloaded, and then elaborates as usual with the exception that overloaded type variables are not allowed to be quantified. (Some examples I've run indicates this.) The following example seems to indicate that you allow unification of overloaded type variables with explicit type variables and when unifying marks the explicit type variables as overloaded. This mark prohibits quantification of the explicit type variable at its scoping declaration, hence violating rule 17 in the Definition. My question is --- why allow unification of overloaded typevariables with explict type variables at all?; since quantification is not allowed, overlaoding cannot be resolved this way (as in let val f = fn x => x + x in f 2 end, which elaborates), so the only other way is to unify the explicit type variable with int or real, which is not allowed, hence overloading cannot be resolved this way either. So what do you gain? Transcript: - let val f = fn (x: 'a) => x + x in f 2 end; std_in:1.5-1.31 Error: explicit type variable cannot be generalized at its scoping declaration: 'a std_in:1.29 Error: overloaded variable "+" cannot be resolved Comment: [dbm] The type variables of the type scheme of an overloaded variable are "marked as overloaded" when an instance of the type scheme is created for a particular applied occurence of the variable. This marking is accomplished by a book-keeping device -- each type metavariable substituted for a bound variable of the scheme is given a "depth" of zero. The depth attribute is used to determine whether a metavariable can be generalized at a val binding, and a depth of zero will prevent these metavariables (or metavariables in types substituted for them) from ever being generalized. When one of these metavariables is unified with a "user-bound" type variable like the 'a in your example, the depth of the metavariable is propagated to the user-bound variable, which in this case prevents the user-bound variable from being generalized at the appropriate place. This looks like a bug -- in fact, I think that the user-bound variable should probably not have a depth attribute at all. Status: not a bug (but alternate handling might be better) ---------------------------------------------------------------------- Number: 617 Title: interpreter fails with "no default in interp" Keywords: interpreter Submitter: Andrew Tolmach (apt@research.att.com) Date: 8/12/92 Version: 0.87 System: mips riscos Severity: major Problem: On a variety of programs, the interpreter fails with "no default in interp". Code: System.Control.interp := true; use "/usr/local/sml/benchmarks/leroy.sml"; (* the standard knuth-bendix benchmark *) Transcript: signature KB = sig datatype ordering con Equal : ordering con Greater : ordering con NotGE : ordering datatype term con Term : string * term list -> term con Var : int -> term val doit : unit -> unit val kb_complete : (term * term -> bool) -> (int * (int * (term * term))) list -> ('a * ('b * (term * term))) list -> unit val lex_ext : (term * term -> ordering) -> term * term -> ordering val rpo : (string -> string -> ordering) -> ((term * term -> ordering) -> term * term -> ordering) -> term * term -> ordering end /usr/local/sml/benchmarks/leroy.sml:603.1-608.22 Warning: match not exhaustive "U" => ... "*" => ... "I" => ... "B" => ... "C" => ... "A" => ... Error: Compiler bug: no default in interp [closing /usr/local/sml/benchmarks/leroy.sml] Comments: Failure to track changes in data representations? If the debugger is built using makeml -i, this bug occurs the first time a usedbg_live is tried. Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 618 Title: LOOKUP FAILS, Compiler bug: 110 in CPSgen Keywords: CPSgen Submitter: Dave MacQueen Date: 8/15/92 Version: 0.87 System: Sparc, Mips Severity: critical Code: (* bug618.sml *) signature S0 = sig exception Error of string (* string arg necessary *) end functor F (X : S0) = struct open X fun extend_one (i,v,r) j = if i = j then v else (r j) (* necessary *) fun extend_env _ = raise Error "foo" end structure A : S0 = struct exception Error of string end structure B = F(A) Transcript: skye$ sml Standard ML of New Jersey, Version 0.87, July 31, 1992 val it = () : unit - use "bug618.sml"; LOOKUP FAILS in close(FIX 2373 ) on 2310 in environment: 2370 2368 2451 2448 2449 2450 2369/callee 2451 - 2448 2449 2450 Error: Compiler bug: 110 in CPSgen [closing bug618.sml] - use "bug618.sml"; Illegal instruction(coredump) skye$ Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 619 Title: Compiler bug: Escapemap on xxxx Keywords: modules, functors, code generation Submitter: Dave MacQueen Date: 8/15/92 Version: 0.87 System: Sparc, Mips Severity: critical Code: (* bug619.sml *) signature SIG = sig exception Error of string end functor F (X : SIG) = struct open X datatype Exp = APP of Exp * (Exp list) datatype Val = FUNC of Val list -> (Val -> unit) -> unit fun extend_one (i,v,r) j = if i = j then v else (r j) fun extend_env([],[],r) = r | extend_env(i::is,v::vs,r) = extend_env(is,vs,extend_one(i,v,r)) | extend_env _ = raise Error "mismatching environment extension" fun meaning (APP(e,es)) r k = meaning e r (fn (FUNC f) => meaninglis es r (fn vs => f vs k)) and meaninglis [] r k = k [] | meaninglis (e :: es) r k = meaning e r (fn v => meaninglis es r (fn vs => k (v :: vs))) end structure A : SIG = struct exception Error of string end structure B = F(A) (* necessary *) Transcript: - skye$ sml Standard ML of New Jersey, Version 0.87, July 31, 1992 val it = () : unit - use "bug619.sml"; Error: Compiler bug: Escapemap on 2423 [closing bug619.sml] - Comment: probably closely related to bug 618. Minor simplifications of the code produce a version of bug 618. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 620 Title: higher-order functor causes Compiler bug Keywords: modules, functors, higher-order functors Submitter: Dave MacQueen Date: 8/15/92 Version: 0.87 Severity: major Problem: Higher order functor definition fails with "Compiler bug: abstractfct:tyconSeries1: param tycon not found" Code: signature SIG = sig datatype d = D of unit (* the "of unit" is necessary for bug *) end functor Twice(functor F(A:SIG):SIG) = struct functor TwiceF(A: SIG) = F(F(A)) end Transcript: - use "bug620.sml"; Error: Compiler bug: abstractfct:tyconSeries1: param tycon not found [closing bug620.sml] Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 621 Title: polymorphic equality not eliminated as often as it should be Keywords: equality, polymorphism Submitter: aitken@cs.cornell.edu (William E. Aitken) Date: 8/13/92 Version: 0.87 (also 0.88b) System: sun4 sunos Severity: minor Problem: polymorphic equality not eliminated as often as it should be Code: val eq = (op =) val eq1 : int * int -> bool = (op =) val eq2 = (op =) : int * int -> bool Transcript: (Script started on Thu Aug 13 11:46:13 1992) ai $ sml Standard ML of New Jersey, Version 0.87, July 31, 1992 val it = () : unit - System.Control.CG.printit := true; val it = () : unit - (* this should be implemented as poly-eq *) = val eq = op =; After convert: 2316(2314,2315) = 2317(2313,2318) = 2319(2320) = 2318((I)0) 2313((I)99,2319) 2317(2314,2315) . . . val eq = - : ''a * ''a -> bool - (* this should be implemented as integer equality, but isn't *) = val eq1 : int * int -> bool = (op =) ; After convert: 2346(2344,2345) = 2347(2343,2348) = 2349(2350) = 2348((I)0) 2343((I)99,2349) 2347(2344,2345) . . . val eq1 = - : int * int -> bool - - (* this should be implemented as integer equality, and is *) = val eq2 = (op =) : int * int -> bool; After convert: 2376(2374,2375) = 2377(2373,2378) = 2379(2380) = 2382(2381,2383) = 2381.0 -> 2384 2381.1 -> 2385 if ieql(2384,2385) [2388] then 2383((I)1) else 2383((I)0) {2382} -> 2389 2378(2389) 2373((I)99,2379) 2377(2374,2375) . . . val eq2 = fn : int * int -> bool (script done on Thu Aug 13 11:47:39 1992) Comments: eq1 implements the equality check as a call to polymorphic equality, while eq2 inline expands the equality for the type int. This is particularly obnoxious since, at least to me, the declaration of eq1 looks prettier. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 622 Title: Bus error on DECstation 5000/200 Keywords: DECstation Submitter: Urban Engberg Date: 8/18/92 Version: 0.75-0.80 System: DECstation 5000/200 and 5000/240 Severity: major Problem: I have been using SML of NJ for a couple of years, mostly for writing compiler-related tools. The tool I am currently working on contains about 7000 lines of sml-code, including the code produced by sml-lex and -yacc. The relatively large size of the program seems essential to my problem to be described. When compiling the code, by reading in the files with "use", the sml system once in a while crashes with messages such as pid 22613 (tlac.orig) was killed on an unaligned access, at pc 0x100a3550 Bus error (core dumped) The problem has been specific to running on DECstations 5000/200 and 5000/240 (at least) but occurs on all the machines of this kind that I have tried. I have been able to bear over with the problems for some time, without trying to find the error, as I would just have to restart the compilation at the right point a couple of times. Lately, however, the problem has started showing up more and more often when I execute the binary image I create with the library-construct "exportFn". As my code has been growing, I have now got a ratio of well-functioning runs to ones crashing of about 1:10! Thus it is beginning to be a very big problem. [added 8/19/92] The problem occurs at random. But running a compilation which takes about five seconds will currently produce the crash nine times out of ten. I am running Ultrix version 4.2A (Apr 92), which I suppose is one of the newest. I remember having had problems all the time since I began using DEC machines though, since March 91. You are quite right in that `unaligned access' errors seems to indicate some sort of Ultrix bug. Comments: [George] This brings back memories of when I was bringing up the new MIPS code generator. The regression tester specifically, would run just fine on a MIPSEB but would crash once in a while in a non-deterministic manner on a MIPSEL. The error message was identical - unaligned access, at pc ... At the time, we concluded that this was an operating system related problem, and not the fault of the generated code. Unfortunately, I did not persist in getting to the root of the problem. I am not able to reproduce the error as the regression tester being used is gone!! My suggestion would be to try a post v 0.82 release that had even less reliance on the operating system - i.e., any trapless gc version. Followup: [Urban Engberg, 8/24/92] It has been making me curious that the errors lately doesn't seem to show up in other programs than my compiler (where it with earlier sml versions has been a problem with many programs, and also when compiling the compiler). So with a good guess, I tried removing some calls I had to `IO.execute'. This made a crucial difference; the compiler now runs without any problems. To help finding the error, it should be noted that the compiler works fine *with* the `IO.execute' commands, when run from within an interactive sml session. I have tried to reproduce the error in a smaller program, but without success. The calls to `IO.execute' looked as follows: val (datestream, dummy) = IO.execute ("/bin/csh", ["-cfb", "/bin/date +\"%a %h %d%H:%M 19%y\""]) val date = input (datestream, 21) before (close_in datestream; close_out dummy) Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 623 Title: wildcard is equivalent to a series of wildcards (see also 629) Keywords: syntax, wildcards Submitter: cregut Date: 20/8/92 Version: .88 System: all Severity: minor/major Problem: wildcard is equivalent to a serie of wildcards Code: fun foo x 0 = x | foo _ = 0; (* this failed in pre-0.88 versions *) Transcript: val foo = fn : int -> int -> int Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 624 Title: System.Env.filterEnv causes Compiler bug: copystat. Keywords: environment, filterEnv Submitter: Gene Rollins Date: 8/21/92 Version: 0.88 Severity: major Problem: System.Env.filterEnv causes compiler bug: copystat. Code: ==== env.sml ==== structure TestEnv = struct fun printEnv (e:System.Env.environment) = app (fn s=> (print ((System.Symbol.makestring s) ^ "\n"))) (System.Env.catalogEnv (System.Env.staticPart e)) val TestStructure = System.Symbol.strSymbol "Test"; fun test() = (use "test.sml"; printEnv (!System.Env.topLevelEnvRef); print "----------\n"; printEnv(System.Env.filterEnv(!System.Env.topLevelEnvRef,[TestStructure]))) end ==== test.sml ==== structure Test = struct val x = 4 end Transcript: Standard ML of New Jersey, Version 0.88, August 14, 1992 - use "env.sml"; structure TestEnv : sig val TestStructure : symbol val printEnv : environment -> unit val test : unit -> unit end - TestEnv.test(); structure Test : sig val x : int end [closing test.sml] STRTAB$Test STRTAB$TestEnv STR$Test STR$TestEnv VAL$it ---------- Error: Compiler bug: copystat - Status: fixed in 0.89 (Cregut) ---------------------------------------------------------------------- Number: 625 Title: Runbind exception still being raised. Keywords: Runbind Submitter: Gene Rollins, Andrew Appel Date: 8/21/92 Version: 0.88 Severity: major Problem: Runbind exception still being raised. Status: fixed in 0.91 (not verified) ---------------------------------------------------------------------- Number: 626 Title: extra spaces in SPARC.prim.s Keywords: assembly Submitter: Gene Rollins Date: 8/21/92 Version: 0.88 System: SPARC Severity: Problem: It appears that our assembler can't handle the extra spaces given in several of the #defines in the original file SPARC.prim.s.0. The new SPARC.prim.s works fine. Here are the differences. They are all within the first 55 lines. Fix: % diff SPARC.prim.s.0 SPARC.prim.s 26c26 < #define exncont g7 /* exception handler (ml_exncont) */ --- > #define exncont g7 /* exception handler (ml_exncont) */ 29,35c29,35 < #define limit g4 /* heap limit pointer (ml_limitptr)*/ < #define stdarg i0 /* standard argument (ml_arg) */ < #define stdcont i1 /* standard continuation (ml_cont) */ < #define stdclos i2 /* standard closure (ml_clos) */ < #define baseptr i3 /* base code pointer (ml_roots[]) */ < #define varptr i5 /* var pointer (ml_varptr) */ < #define stdlink g1 --- > #define limit g4 /* heap limit pointer (ml_limitptr)*/ > #define stdarg i0 /* standard argument (ml_arg) */ > #define stdcont i1 /* standard continuation (ml_cont) */ > #define stdclos i2 /* standard closure (ml_clos) */ > #define baseptr i3 /* base code pointer (ml_roots[]) */ > #define varptr i5 /* var pointer (ml_varptr) */ > #define stdlink g1 49,53c49,53 < #define tmp1 o2 < #define tmp2 o3 < #define tmp3 o4 < #define tmp4 o5 /* also used to pass register mask to g.c. */ < #define gclink o7 /* link register for return from g.c. (ml_pc) */ --- > #define tmp1 o2 > #define tmp2 o3 > #define tmp3 o4 > #define tmp4 o5 /* also used to pass register mask to g.c. */ > #define gclink o7 /* link register for return from g.c. (ml_pc) */ Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 627 Title: blast-writing objects outside the heap leads to failure Keywords: I/O, blast_write Submitter: David Tarditi Date: 8/21/92 Version: 0.88 Severity: major Problem: blast-write fails when given an object that is outside the heap. The following program (for version 0.75, shareable) demonstrates this. You'll have to change the program slightly to run it in the latest version of the compiler, since the type of blast_read has changed. Code: structure blast = struct val s = System.version val outblast = fn () => let val outfd = open_out "testblast" in (System.Unsafe.blast_write (outfd, s); close_out outfd) end val inblast = fn () => let val infd = open_in "testblast" val res : string = System.Unsafe.blast_read infd val _ = close_in infd in (print "Got back: "; print res; print " : from testblast\n") end val _ = outblast () val _ = inblast () end Transcript: - use "/usr/dtarditi/tmp"; [opening /usr/dtarditi/tmp] [Major collection...abandoned] Got back: : from testblast structure blast : sig val inblast : unit -> unit val outblast : unit -> unit val s : string end [closing /usr/dtarditi/tmp] val it = () : unit Comments: In the shareable version of the compiler, where the code for the compiler is palced outside the heap, the string System.version ends up outside the heap. Fix: The solution is to add a check to the code for blast-write, I think, for the case where the object being blasted out is a pointer that is outside the heap. [Tarditi, 8/21/92:] I remember there was some problem about import not working across different compiled versions of the same compiler. For example, I think import files created with a shareable version of the compiler caused the nonshared version to crash. I've realized what the problem is, and it is worth noting down for future reference. The basic problem is that blast_write isn't fully generally, and only works with a particular executable. If you blast-write an object which contains pointers that are outside the heap, the garbage collector just copies the pointers as though they were integers. The problem is that with different executables, the objects outside the heap may not exist at all, may be different (that is, the pointer points to junk), or they may be at a different address. Think about what happens when you blast-write a function. The function will most likely contain objects from the pervasive environment in its closure. Suppose one of those objects from the pervasive environment is a closure. It will contain a code pointer. If the compiler is shareable version, the code pointer will be outside the heap. Now, if we try to read blast_read this function into a nonshareable version of the compiler, the code pointer will be junk! Note that you'll have this problem even if only the runtime has been changed across executables. This will change the address of code for the assembly language primitives, and the addresses of ML objects allocated as static C data structures. A possible solution to add a level of indirection between objects in the runtime system and blast-written objects. (1) give every possible ML object in the runtime system a unique name (2) when blast-writing an object, translate ML objects outside the heap to their unique names (3) when blast-reading an object, translate from the unique names back to the ML objects. We could hack something up to deal with the code strings for the pervasives being either in the heap or text segment. We'd have to put a limitation that you can only blast-read/blast-write objects outside the heap which are "registered" (i.e. you can't blast-write things like the code for the compiler). At least things could fail gracefully instead of crashing. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 628 Title: System.Env.filterEnv broken (accidental duplicate of 624) Status: fixed in 0.89 (Cregut) ---------------------------------------------------------------------- Number: 629 Title: fun declaration syntax (see 623) Keywords: syntax, fun declaration Submitter: aitken@cs.cornell.edu (William E. Aitken) Date: 8/29/92 Version: 0.88 (back to 0.83 -- worked in 0.82) System: Sun 4m/670 MP Sparc, SunOS Release 4.1.2 Severity: minor Problem: function declarations made using `fun' may arbitrarily mix clauses in which the formal parameters are curried and clauses in which they are uncurried. Note that if they are uncurried, the formal pattern must be of n-tuple type. That is, it may be a variable pattern or a wildcard pattern or a tuple pattern of the appropriate arity. Code: fun foo 1 x = 17 | foo (a, b) = a + b fun bar (1, x) = 17 | bar a b = a - b fun splat a b = 4 | splat x = 5 Transcript: % sml Standard ML of New Jersey, Version 0.88, August 14, 1992 val it = () : unit - fun foo 1 x = 17 = | foo (a, b) = a + b; val foo = fn : int -> int -> int - fun bar (1, x) = 17 = | bar a b = a - b; val bar = fn : int * int -> int - fun splat a b = 4 = | splat x = 5; std_in:5.17-6.15 Warning: redundant patterns in match (a,b) => ... x => ... val splat = fn : 'a -> 'b -> int - ^D % Comments: There are two function declarations in translate/tempexpn.sml that (accidentally) exploit this bug. They are the last two functions of the structure. In the first case, the second argument needs to be uncurried, in the second case, the final clause needs a second wildcard pattern. Similarly, the function labBranchOff in mips/mipsinstr.sml, needs a second wildcard pattern in its final clause's formal parameters. The problem occurs because no explicit test is ever made to ensure that clauses have the same number of argument patterns. In elaborating a function declaration, the compiler produces something of the form fn x1 => ... => fn xn => case (x1, ..., xn) of p1 => e1 . . . pm => em x1, ..., xn are distinct new variables. ei is the expression of the ith clause. n is the number of patterns in the *first* clause If the ith clause has r > 1 patterns (pi1, ..., pir), pi is the the pattern (pi1, ..., pir). If the ith clause has only one pattern, pi is that pattern. The type checker will detect most mis-matches between numbers of arguments --- e.g., fun foo a b c = 4 | foo a b = 5; std_in:7.17-7.31 Error: rules don't agree (tycon mismatch) expected: 'Z * 'Y * 'X -> int found: 'W * 'V -> int rule: (a,b) => 5 but will not catch mis-matches between appropriately typed single patterns and multiple patterns. Fix: Add a check that the number of formal parameters agrees in each clause. Rewriting checkFB in parse/astutils.sml as follows should work, the compiler compiles itself to a fixpoint with it installed, but I have *not* tested the resulting code very thoroughly. (Note that translate/tempexpn.sml and mips/mipsinstr.sml need to be fixed too, as described above). fun checkFB(clauses as ({name,pats,...}:rawclause)::rest, err) = let val patslen = length pats in if exists (fn {name=n,...} => not(Symbol.eq(n,name))) rest then err COMPLAIN "clauses don't all have same function-name" else if exists (fn {pats=p,...} => length p <> patslen) rest then err COMPLAIN "clauses don't all have same number of patterns" else (); clauses end | checkFB _ = ErrorMsg.impossible "CoreLang.checkFB" if calculating the length is too expensive here, using the function fun len1 [x] = true | len1 _ = false will suffice, at the expense of less good error reporting. Status: same as 623 ---------------------------------------------------------------------- Number: 630 Title: smallest number literal in patterns (same as 507) Keywords: literals, patterns Submitter: aitken@cs.cornell.edu (William E. Aitken) Date: 8/29/92 Version: 0.88 System: Sun 4m/670 MP Sparc, SunOS Release 4.1.2 Severity: minor Problem: the special constant denoting the smallest member of the type int (~1073741824) causes compilation failure if it appears in patterns. It is legal in expressions. Code: fun foo ~1073741824 = 5 | foo x = 3 Transcript: % sml Standard ML of New Jersey, Version 0.88, August 14, 1992 val it = () : unit - ~1073741824; val it = ~1073741824 : int - fun foo ~1073741824 = 5 | foo x = 3; Error: Compiler bug: Overflow in cps/generic.sml - ~1073741824; val it = uncaught exception Boxity - ~1073741824; val it = ~1073741824 : int 1073741824; std_in:2.1-2.10 Error: integer too large - ^D % Comments: If I've already submitted this bug, sorry. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 631 Title: PrintVal can't print a value of the Ast type Keywords: printing Submitter: cregut Date: 8/29/92 Version: from .86 System: sparc mips.. Severity: Problem: PrintVal can't print a value of the Ast type Code: (* int.sml *) structure interface = struct local open System.Compile System.Env in fun ast name = let val f = open_in name val source = makeSource (name,0,f,false,std_out) val (ast : System.Ast.dec,_) = parse(source,staticPart (!pervasiveEnvRef)) in ast end end end Transcript: - use "int.sml"; structure interface : sig val ast : string -> System.Ast.dec end [closing int.sml] val it = () : unit - interface.ast "int.sml"; val it = SeqDec [MarkDec (Error: Compiler bug: PrintVal.switch: none of the data cons matched - Comments: The AST type is built in parse/ast.sml but another version is in system.sig and perv.sml so that the user can access it. It is not a problem of consistency of defs (no changes with 85). Fix: make sure ast.sml is compiled with newconreps having the same value that will be default for the user. That is, put "^newconreps !ast.sml ^newconreps" in the "all" file. Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 632 Title: minimal or maximal integer literals in patterns cause compiler bug Keywords: literals, patterns Submitter: aitken@cs.cornell.edu (William E. Aitken) Date: 8/30/92 Version: 0.88, also 0.75 System: SunOS Release 4.1.2, Sun 4m/670 MP Sparc Severity: major Problem: Integer patterns larger than 2^29-1 or smaller than ~2^29 trigger a compiler bug. Code: fun foo 0x20000000 = true | foo x = false; Transcript: Standard ML of New Jersey, Version 0.88, August 14, 1992 val it = () : unit - fun foo 0x20000000 = 5 ; std_in:2.1-2.22 Warning: match not exhaustive 536870912 => ... Error: Compiler bug: Overflow in cps/generic.sml - 12; val it = uncaught exception Boxity - fun foo ~0x20000000 = 5 ; std_in:0.0-0.0 Warning: match not exhaustive ~536870912 => ... val foo = fn : int -> int - fun foo ~0x20000001 = 5; std_in:2.1-2.23 Warning: match not exhaustive ~536870913 => ... Error: Compiler bug: Overflow in cps/generic.sml - Comments: This is just a generalization of a bug reported yesterday. Status: same as 507 ---------------------------------------------------------------------- Number: 633 Title: space leak Keywords: space leak, memory management Submitter: John Reppy Date: 1/9/92 Version: 0.88 Severity: major Problem: The old space leak in capture/escape seems to have reappeared. I ran my test on versions 0.75-0.88, and here is a summary of the results: version space leak? 75 no 76 no 77 yes 78 yes 79 yes 80 yes 81 no 82 no 83 no 84 yes 85 yes 86 yes 87 yes 88 yes Note that the two rounds of contract before eta were eliminated in version 0.84. As a reminder, the simple example of this problem is the function select. Code: local open System.Unsafe.PolyCont in fun select x = capture (fn k => let val return = escape k in return (x ()) end) end; which is called in the following loop: fun loop () = select loop Comments: This should be constant space! Status: fixed in 0.90 (again!) ---------------------------------------------------------------------- Number: 634 Title: Uncaught expception NotDirectory Keywords: Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 9/4/92 Version: 0.88 System: mipsb/riscos and mipsl/ultrix Severity: major Problem: Uncaught expception NotDirectory Code: (************************************************************************** * THIS IS THE FILE getwd.sml --------- Modified from SourceGroup * * version 2.2 tools/sourcegroup/local/System/getwd.sml * **************************************************************************) structure GetWorkingDirectory :sig val getwd :unit -> string end = struct fun withInOutStreams (inS :instream, outS :outstream) (action :instream * outstream -> 'a -> 'b) (argument:'a) :'b = let val result = action (inS, outS) argument handle exn => (close_in inS; close_out outS; raise exn) in close_out outS; close_in inS; result end val SYS_wait = 84 fun waitForProcess () = (while (((System.Unsafe.CInterface.syscall (SYS_wait, System.Unsafe.cast 0)) handle System.Unsafe.CInterface.SysError _ => 0) > 0) do ()) fun firstLine (program:string, args :string list) = let fun strip_newline str = let val len = size str in if len > 0 then substring (str, 0, len - 1) else str end fun first_line (inS,outS) () = strip_newline (input_line inS) val result = withInOutStreams (execute (program, args)) first_line () in waitForProcess(); result end fun getwd () = firstLine ("/bin/pwd", []) end val _ = (let val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd val cwd = GetWorkingDirectory.getwd() val _ = System.Directory.cd cwd in print "\n \n This is correct! \n \n" end) handle _ => (print "\n\n This is wrong, Why exceptions? \n\n") Transcript: - use "getwd.sml"; This is wrong, Why exceptions? structure GetWorkingDirectory : sig val getwd : unit -> string end [closing /u/zsh/tcps/work/new/bug/tt.sml] val it = () : unit - Comments: "Uncaught exception NotDirectory" happened RANDOMLY(50%) when doing "val cwd = GetWorkingDirectory.getwd(); System.Directory.cd cwd;" This is why I did ten runs of it in the above script. I suspect the getwd.sml in SourceGroup is coded in an incompatible way with the version 88's Directory.cd function in perv.sml (or runtime/cfuns.c), since the above bug did not occur in 87. This bug occurs (sometimes,say one out of two times) when making smlsg using version88. ** This is probably another example of bug #651 (JHR, 10/6/92) ** Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 635 Title: ByteArray.update and ByteArray.sub raise Ord Keywords: ByteArray Submitter: Robert Cooper (rcbc@cs.cornell.edu) Date: 9/10/92 Version: 0.75 (broken in 0.89) System: any Severity: minor Problem: ByteArray.update and ByteArray.sub raise Ord instead of Subscript Transcript: Standard ML of New Jersey, Version 0.89, September 4, 1992 val it = () : unit - open ByteArray; open ByteArray - val a = array(2, 0); val a = - : bytearray - update (a, 2, 100); uncaught exception Ord - a sub 2; uncaught exception Ord Comments: The inline operators are incorrectly defined. Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 636 Title: Vector patterns don't work at top level Keywords: vectors, patterns, top level Submitter: Dave MacQueen Date: 9/10/92 Version: 0.88 Severity: major Problem: Vector patterns don't work at top level Transcript: Standard ML of New Jersey, Version 0.89, September 4, 1992 val it = () : unit - val v = #[1,2,3]; val v = #[1,2,3] : int vector - val #[a,b,c] = v; std_in:5.1-5.16 Warning: binding not exhaustive #[a,b,c] = ... - a; uncaught exception IntmapF - let val #[a,b,c] = v in a end; std_in:0.0-0.0 Warning: binding not exhaustive #[a,b,c] = ... val it = 1 : int Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 637 Title: Compiler bug printing signatures with polymorphic exceptions (same as 613) Keywords: modules, signatures, printing Submitter: Gene Rollins Date: 9/10/92 Version: 0.88? Severity: minor Problem: The Compiler reports a compiler bug when trying to print signatures that contain polymorphic exceptions. This happens with both 0.75 and 0.80 versions on both sun4 and decstation machines running mach. Code: Transcript: - signature SEQUENCE = sig exception no_next of 'a end; signature SEQUENCE = sig exception no_next of Error: Compiler bug: domain Comments: If we set: System.Control.Print.signatures := 0; the compiler compiles the signature fine, and does not report the compiler bug. [DBM:] Polymorphic exception specifications in signatures are (or should be) illegal, so these should cause some error message. Status: same as 613 ---------------------------------------------------------------------- Number: 638 Title: subnormal numbers Keywords: floats, literals Submitter: Appel Date: 9/15/92 Version: 0.89 System: Sparc Severity: minor Problem: The "ln" function does not expect subnormal numbers, and gives wrong answers. Other functions may have similar problems. Code: Transcript: val x = 1.0E~160; val x = 1.0E~160 : real - x * x; val it = 9.99988867182683E~321 : real - ln it; val it = ~4.05753556581235 : real - Comments: Fix: Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 639 Title: multiple compiler compilations on sparc fail Keywords: sparc Submitter: Pierre Cregut Date: 9/15/92 Version: 0.89 System: SunOS 4.1, SPARC 2, 64MB Severity: major Problem: When multiple compilations of the ML compiler are launched on a single sparc 2, some of them fail with "Bus error" or "Segmentation fault". Transcript: I have done the experiment but forgot it... so here is the result of launching 3 smlc (.89) on skye One is Ok and has finished... another: > [closing elaborate/normalize.sml] > [Compiling modules/moduleutil.sml] > structure ModuleUtil : ... > > [Major collection... 7% used (1403140/20038536), 1040 msec] > Bus error and the last > signature GENERAL = ... > [closing boot/perv.sig] > [Loading boot/system.sig] > > [Increasing heap to 24114k] > Segmentation fault who died very quickly !! Comments: Why did it asked for such a swap space suddenly: it is completely ridiculous at that point... Status: obsolete ---------------------------------------------------------------------- Number: 640 Title: flakiness of System.Env (particularly filterEnv) Keywords: environment, filterEnv Submitter: Sanjiva Prasad Date: 9/16/92 Version: 0.88 Severity: major Problem: Perhaps someone in your group has already discovered and fixed these bugs in v88. We had pulled over a copy of v88 to experiment with the new environment features you had advertised (with the intention of trying out an mini interpreter that does not maintain the application environment, but evaluates a syntax tree in a given environment). I mucked around a bit, trying to create some small environments by making type, structure, functor and value declarations, then using map, some list operations like rev and some auxiliary functions, and (from System.Env) catalogEnv, topLevelEnvRef, staticPart and filterEnv. Unfortunately, I kept getting Compiler Bug messages when I used filterEnv (I organized my program carefully enough to isolate the occurrence of these to the use of filterEnv). The ugly part of the story is that although repeating the evaluation resulted in the same bug message or exception being raised, there was no pattern to it. For instance, filtering out an environment from the top-level environment using a list of seven symbols -- obtained from applying staticPart and then catalogEnv -- resulted in a compiler bug message "compstat" (I think it was that). With a different list (again obtained using list operations, catalogEnv, staticPart and topLevelEnvRef), I got uncaught exception IntmapF, and then with another list (this time built using string-to-symbol functions in System.Symbol), I got another compiler bug (I can't recall which). In all cases, it is when trying to use filterEnv. Comment: [dbm] can't reproduce Status: not reproducible ---------------------------------------------------------------------- Number: 641 Title: higher-order functors give Compiler bug: PrintVal.switch: none ... Keywords: modules, functors, higher-order functors, printing Submitter: Sanjiva Prasad Date: 9/16/92 Version: 0.88 Severity: major Problem: Use of higher-order functors results in Compiler bug when a value of a datatype is printed. Transcript: - signature SIG1 = sig type t type u val x:t val y:u end; signature SIG1 = sig type t type u val x : t val y : u end - structure A:SIG1 = struct type t=int type u=bool val x=5 val y=true end; structure A : SIG1 - - signature SIG2 = sig = functor Foo(X:SIG1) : sig val z : A.t val w: X.t end = end; (* This was to test if the restriction on what names may be used -- relevant for separate compilation -- was enforced in v88 *) signature SIG2 = sig functor Foo : end - structure B : SIG2 = struct functor Foo(X:SIG1) = struct val z = A.x + 1 val w = X.x = type foo = bool = end = end; structure B : SIG2 (* This was to test if signature contraints of SIG2 were propagated down to the body of the functor. Pleasantly, it is *) - open B; open B - structure C = Foo(A); structure C : sig val z : A.t val w : A.t end - structure D :SIG1 = struct type t = bool type u = int val x = false val y = 7 end; structure D : SIG1 - structure E = Foo(D); structure E : sig val z : A.t val w : D.t end - C.w; val it = 1 : A.t (* should have been equal to A.x = 5 !!!!! *) - A.x; val it = 5 : A.t - C.z; val it = 6 : A.t (* rightly so *) - E.z; val it = 6 : A.t (* again rightly so *) - E.w; (* should have been false *) val it = Error: Compiler bug: PrintVal.switch: none of the datacons matched Status: fixed in 0.89 ---------------------------------------------------------------------- Number: 642 Title: Sourcegroup 2.1 dependency analysis fails (see also bug 649) Keywords: Sourcegroup Submitter: Amy Felty, felty@research.att.com Date: 9/17/92 Version: 0.90a System: sun4 sparc Severity: major Problem: SG2.1 compiles, but doesn't execute propery. The last version that I know of where it works properly is 0.87. In a call to SourceGroup.make, one of the arguments is the name of the top-level functor (ElpSymtab in this example). It should then be able to determine all the necessary files to compile and build the structures. Instead, it replies with: % structure ElpSymtab undefined Code: I have put a tar file in ~felty/lp-sml/SGbug.tar. It is not very large, but contains files in several subdirectories. (It is a very small piece of the Lambda Prolog code.) Transcript: I'm including a transcript of the execution in 0.90a with the bug, followed by a transcript of the working version in 0.87. ------------------------ transcript for SML 0.90a ------------------------ % /usr/local/sml/bin/sparc/sml-sg.90a Standard ML of New Jersey, Version 0.90a September 16, 1992 with SourceGroup 2.1 built on Wed Sep 16 20:11:34 EDT 1992 val it = () : unit - use "build.sml"; val it = () : unit val it = () : unit val it = () : unit structure SG : SOURCEGROUP structure SA : SOURCEACTION structure FL : FILELIST val smlFiles = fn : string list -> string list val mlyaccFiles = fn : string list -> string list hash/Hash.sig hash/Hash.sml hash/link-hash.sml val hashGroup = 1 : ?.group sys/hasher.sml sys/link-sys.sml sys/location.sml sys/profile.sml sys/sys.sig sys/sys_newjersey.fun sys/time.sml val sysGroup = 3 : ?.group val libraries = [1,3] : ?.group list [closing group-libraries.sml] val it = () : unit lam/basic.fun lam/basic.sig lam/term.fun lam/term.sig lam/naming.fun lam/naming.sig val lamGroup = 5 : ?.group elp/elp_symtabs.fun elp/elp_symtabs.sig elp/link-elp.sml val elpGroup = 7 : ?.group val makeElp = fn : unit -> unit [closing group.sml] val it = () : unit val make = fn : unit -> unit % structure ElpSymtab undefined val it = () : unit [closing build.sml] val it = () : unit ----------------------- transcript for SML 0.87 ----------------------- % /usr/local/sml/bin/sparc/sml-sg Standard ML of New Jersey, Version 0.87, July 31, 1992 with SourceGroup 2.1 built on Mon Aug 3 14:02:28 EDT 1992 val it = () : unit - use "build.sml"; val it = () : unit val it = () : unit val it = () : unit structure SG : SOURCEGROUP structure SA : SOURCEACTION structure FL : FILELIST val smlFiles = fn : string list -> string list val mlyaccFiles = fn : string list -> string list hash/Hash.sig hash/Hash.sml hash/link-hash.sml val hashGroup = 1 : ?.group sys/hasher.sml sys/link-sys.sml sys/location.sml sys/profile.sml sys/sys.sig sys/sys_newjersey.fun sys/time.sml val sysGroup = 3 : ?.group val libraries = [1,3] : ?.group list [closing group-libraries.sml] val it = () : unit lam/basic.fun lam/basic.sig lam/term.fun lam/term.sig lam/naming.fun lam/naming.sig val lamGroup = 5 : ?.group elp/elp_symtabs.fun elp/elp_symtabs.sig elp/link-elp.sml val elpGroup = 7 : ?.group val makeElp = fn : unit -> unit [closing group.sml] val it = () : unit val make = fn : unit -> unit [reading sys/time.sml] [closing sys/time.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/time.sml.bin] signature TIME functor Time [reading sys/sys.sig] [closing sys/sys.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/sys.sig.bin] signature SYS [reading sys/sys_newjersey.fun] [closing sys/sys_newjersey.fun] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/sys_newjersey.fun.bin] functor NewJersey [reading sys/location.sml] [closing sys/location.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/location.sml.bin] signature LOCATION functor Location [reading sys/hasher.sml] [closing sys/hasher.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/hasher.sml.bin] functor Hasher signature HASHER [reading sys/link-sys.sml] [closing sys/link-sys.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/sys/.@sys/link-sys.sml.bin] [reading lam/term.sig] [closing lam/term.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/term.sig.bin] signature TERM [reading lam/term.fun] [closing lam/term.fun] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/term.fun.bin] functor Term [reading lam/naming.sig] [closing lam/naming.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/naming.sig.bin] signature NAMING [reading lam/basic.sig] [closing lam/basic.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/basic.sig.bin] signature BASIC [reading lam/naming.fun] [closing lam/naming.fun] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/naming.fun.bin] functor Naming [reading lam/basic.fun] [closing lam/basic.fun] [writing /shadow/12/people/felty/lp-sml/SGtest/lam/.@sys/basic.fun.bin] functor Basic [reading hash/Hash.sig] [closing hash/Hash.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/Hash.sig.bin] signature HASH [reading hash/Hash.sml] [closing hash/Hash.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/Hash.sml.bin] functor HashFun [reading hash/link-hash.sml] [closing hash/link-hash.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/hash/.@sys/link-hash.sml.bin] [reading elp/elp_symtabs.sig] [closing elp/elp_symtabs.sig] [writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/elp_symtabs.sig.bin] signature ELPSYMTAB [reading elp/elp_symtabs.fun] [closing elp/elp_symtabs.fun] [writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/elp_symtabs.fun.bin] functor ElpSymtab [reading elp/link-elp.sml] [closing elp/link-elp.sml] [writing /shadow/12/people/felty/lp-sml/SGtest/elp/.@sys/link-elp.sml.bin] val it = () : unit [closing build.sml] val it = () : unit Comments: Lal and John suggest that a regression test be made for source groups. Status: fixed in 0.91 (Shao) ---------------------------------------------------------------------- Number: 643 Title: building smld produces Compiler bug: DebugError: ... Keywords: debugger, building Submitter: John Reppy (jhr@research.att.com) Date: 9/17/92 Version: 0.89 System: n.a. Severity: major Problem: attempting to build smld produces an error Code: makeml -debug -sun4 sunos Transcript: makeml> (cd runtime; make clean) rm -f *.o lint.out prim.s linkdata allmo.s run makeml> rm -f mo makeml> ln -s ../mo.sparc mo ... [closing dbguser/hstore.sml] val it = () : unit val it = () : unit [debugging support included] structure DebugList : LIST [closing dbguser/list.sml] val it = () : unit Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking [closing dbguser/general.sml] [closing dbguser/load.sml] Comments: This works in version 0.88. Comments: [APT] I looked in and looked at this briefly. I suspect some complication due to the introduction of type options in the absyn. The correct way to diagnose this sort of problem is: 1) use makeml -debug0 to build a debugger version that doesn't attempt to execute dbguser/load.sml. 2) execute dbguser/load.sml up to the file that causes problems. 3) Set System.Control.debugging := true. Under the debugger, this will cause the absyn of the pre- and post-instrumented versions of the code to be printed. 4) Try using "dbguser/general.sml" (in this case) and look where the MARKexps come in the absyn. Compare this to what the code in debug/static.sml (where the exception was raised) is expecting. If you don't get anywhere with this, please leave the result of step 1 around in 89/bin/mipsb (I usually call it smld0) and let me know; I'll try diagnosing from here. Unfortunately, my machine is not up yet here, and telneting cross country is painfully slow... I should have a proper environment for looking at this sort of bug by early next week. Status: obsolete ---------------------------------------------------------------------- Number: 644 Title: checking for stale continuations Keywords: continuations Submitter: MacQueen Date: 9/17/92 Version: 0.89 Severity: major Problem: Checking for stale continuation returns at top level has been disabled (possibly by one of Tolmach's changes to interact). Comments: See bug 145. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 645 Title: Compiler bug from bugs 183,228,343 code: CoreInfo.coreLty3 Keywords: CoreInfo Submitter: Lal George Date: 9/18/92 Version: 0.90 System: Sparc, SunOS Severity: major Problem: Code for bugs 183, 228, 343 now causes "Error: Compiler bug: CoreInfo.coreLty3". Code: /usr/local/sml/testing/bugs/tests/bug183.sml, etc. Status: fixed in 0.91 (Shao) ---------------------------------------------------------------------- Number: 646 Title: module test file mod14.sml fails with Compiler bug: ModuleUtil: getFctStamp Keywords: modules, functors, higher-order functors Submitter: Lal George (regression testing) Date: 9/18/92 Version: 0.90a (& 0.89) Severity: major Problem: Module test case mod14.sml in /usr/local/sml/testing/hof/tests/mod14.sml fails with "Compiler bug: ModuleUtil: getFctStamp". Status: fixed in 0.90 ---------------------------------------------------------------------- Number: 647 Title: PWR_2_CALLEESAVE not defined in some cases Keywords: code generation, registers, callee-saves Submitter: Kjeld H. Mortensen (kjeld@metasoft.com) Date: 9/22/92 Version: 0.89 System: HP9000s400 HPUX8.0 Severity: minor Problem: PWR_2_CALLEESAVE not defined in some cases, which shows up when assembling prim.s. Code: PWR_2_CALLEESAVE will not be defined when CALLEESAVE is already defined. This happens when HPUX (and M68) is defined, because makeml has a special case for this and ends up calling cpp with -DCALLEESAVE=... Transcript: Comments: Fix: If CALLEESAVE, HPUX, and M68 is defined then PWR_2_CALLEESAVE should be set to 1 because CALLEESAVE has the default value 0. I don't know if there are other cases (e.g. if -callee is used with makeml). Status: obsolete ---------------------------------------------------------------------- Number: 648 Title: Compiler core dumps in the boot process for HP9000s400 HPUX8.0 Keywords: hppa Submitter: Kjeld H. Mortensen (kjeld@metasoft.com) Date: 9/22/92 Version: 0.89 System: HP9000s400 HPUX8.0 Severity: critical Problem: Compiler core dumps in the boot process Code: Transcript: Both 'makeml -m68 hpux8 -noshare' and 'makeml -m68 hpux8' results in a core dump ("Illegal instruction" or "Memory fault"). neptune 65: makeml -m68 hpux8 -noshare makeml> (cd runtime; make clean) rm -f *.o lint.out prim.s linkdata allmo.s run makeml> rm -f mo makeml> ln -s ../mo.m68 mo makeml> (cd runtime; rm -f run allmo.o allmo.s) makeml> (cd runtime; ...) makeml> /lib/cpp -DCALLEESAVE=0 -DM68 -DHPUX -DASM M68.prim.s > prim.s makeml> emacs -batch -l sun2hp.el prim.s prim.s Wrote /d1/release/tools/njsml/work89/src/runtime/prim.s makeml> as -o prim.o prim.s makeml> (cd runtime; make MACHINE=M68 'DEFS= -DHPUX' CPP=/lib/cpp 'CFL=-Wl,-a,archive' 'AS=as' 'LIBS=') cc -O -Wl,-a,archive -DM68 -DHPUX -c run.c cc -O -Wl,-a,archive -DM68 -DHPUX -c run_ml.c cc -O -Wl,-a,archive -DM68 -DHPUX -c callgc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c gc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c export.c cc -O -Wl,-a,archive -DM68 -DHPUX -c timers.c cc -O -Wl,-a,archive -DM68 -DHPUX -c ml_objects.c cc -O -Wl,-a,archive -DM68 -DHPUX -c cfuns.c cc -O -Wl,-a,archive -DM68 -DHPUX -c cstruct.c cc -O -Wl,-a,archive -DM68 -DHPUX -c signal.c cc -O -Wl,-a,archive -DM68 -DHPUX -c exncode.c cc -O -Wl,-a,archive -DM68 -DHPUX -c malloc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c mp.c cc -O -Wl,-a,archive -DM68 -DHPUX -c sync.c cc -O -Wl,-a,archive -DM68 -DHPUX -c allmo.c "allmo.c", line 15: warning: incorrect combination of pointer and integer for operator '=' cc -O -Wl,-a,archive -DM68 -DHPUX -o run run.o run_ml.o callgc.o gc.o export.o timers.o ml_objects.o cfuns.o cstruct.o signal.o exncode.o malloc.o mp.o sync.o prim.o allmo.o makeml> echo ( exportML "sml"; output(std_out,System.version); output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 -h 2048 IntM68 [Increasing heap to 2048k] [Loading mo/CoreFunc.mo] [Executing mo/CoreFunc.mo] [Loading mo/Initial.mo] ... [Loading ArrayExt] [Executing ArrayExt] [Executing TypesUtil] [Loading Sort] makeml: 988 Illegal instruction - core dumped neptune 66: Comments: The compiler boots fine on a Sun3, so it doesn't have to be an MC680x0 related problem. Comments: [Kjeld] I have an additional comment: if -g is turned on in runtime/Makefile (i.e. all the runtime sources are compiled with -g and without -O), SML/NJ will boot. BUT, the compiler is flaky. It dumps a core if large integers are evaluated, and it yields compiler bug messages now and then in code that was compiled successfully on previous versions. Let me know if I can be of any help. I'm not sure what the right way is for debugging this. **** From Kjeld H. Mortensen, 11/22/92, version 0.92: I have tried to build the compiler on our HP9000s400. In order to get to the boot point I had to make the following modifications: ------------------------- diff cfuns.c.orig cfuns.c (because the gethostid call isn't known) ------------------------- 30a31,33 > #ifdef HPUX > #include > #endif 1432a1436,1446 > #ifdef HPUX > char buf[SNLEN+1]; > ML_val_t name; > struct utsname utsname; > > uname(&utsname); > bcopy ((char *)(utsname.idnumber), buf, SNLEN); > buf[SNLEN] = '\0'; /* insure null termination */ > name = ML_alloc_string (msp, buf); > RETURN(msp, name); > #else /* !HPUX */ 1442c1456 < --- > #endif /* HPUX */ ----------------------------- diff sun2hp.el.orig sun2hp.el (see also 564 in the masterbugs list) ----------------------------- 97,98c98 < (goto-char point) < (beginning-of-line) --- > (goto-char (- point 2)) 137a138 > (replace-re "\\.word" "short") The last change (converting .word to short) is new, and is thus not mentioned in 564. These changes allowed me to get to the boot point (i.e. all C-sources could be compiled). But then the compiler dumped a core. So, I have the following bug report: =========================================== Submitter: Kjeld H. Mortensen (kjeld@metasoft.com) >Date: 11/22/92 Version: 0.92 System: HP9000s400 (M68k), HPUX 8.0 Severity: Major Problem: Compiler fails to boot. Code: Transcript: neptune 180: makeml -m68 hpux8 -noshare makeml> (cd runtime; make clean) rm -f *.o lint.out prim.s linkdata allmo.s run makeml> rm -f mo makeml> ln -s ../mo.m68 mo makeml> (cd runtime; rm -f run allmo.o allmo.s) makeml> (cd runtime; ...) makeml> /lib/cpp -DCALLEESAVE=0 -DM68 -DHPUX -DASM M68.prim.s > prim.s makeml> emacs -batch -l sun2hp.el prim.s prim.s Wrote /d1/release/tools/njsml/work92/src/runtime/prim.s makeml> as -o prim.o prim.s makeml> (cd runtime; make MACHINE=M68 'DEFS= -DHPUX' CPP=/lib/cpp 'CFL=-Wl,-a,archive' 'LDFLAGS=' 'AS=as' 'LIBS=') cc -O -Wl,-a,archive -DM68 -DHPUX -c run.c cc -O -Wl,-a,archive -DM68 -DHPUX -c run_ml.c cc -O -Wl,-a,archive -DM68 -DHPUX -c callgc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c gc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c export.c cc -O -Wl,-a,archive -DM68 -DHPUX -c timers.c cc -O -Wl,-a,archive -DM68 -DHPUX -c ml_objects.c cc -O -Wl,-a,archive -DM68 -DHPUX -c cfuns.c cc -O -Wl,-a,archive -DM68 -DHPUX -c cstruct.c cc -O -Wl,-a,archive -DM68 -DHPUX -c signal.c cc -O -Wl,-a,archive -DM68 -DHPUX -c exncode.c cc -O -Wl,-a,archive -DM68 -DHPUX -c malloc.c cc -O -Wl,-a,archive -DM68 -DHPUX -c mp.c cc -O -Wl,-a,archive -DM68 -DHPUX -c sync.c cc -O -Wl,-a,archive -DM68 -DHPUX -c allmo.c cc -O -Wl,-a,archive -DM68 -DHPUX -o run run.o run_ml.o callgc.o gc.o export.o timers.o ml_objects.o cfuns.o cstruct.o signal.o exncode.o malloc.o mp.o sync.o prim.o allmo.o makeml> echo ( exportML "sml"; output(std_out,System.version); output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 -h 2048 IntM68 [Increasing heap to 2048k] [Loading mo/CoreFunc.mo] [Executing mo/CoreFunc.mo] [Loading mo/Initial.mo] [Executing mo/Initial.mo] Initial done [Loading mo/Loader.mo] [Executing mo/Loader.mo] makeml: 3591 Memory fault - core dumped Comments: - I have been succesful building the compiler without '-noshare', but sometimes it gives a bus error when it gets to "Go for it". - The version that was successfully build with 'makeml -m68 hpux8' dumps a core when evaluating an integer that is too large: neptune 205: sml Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - 536870911; (* 2^29 - 1 *) val it = 536870911 : int - 536870912; (* 2^29 *) Illegal instruction (core dumped) - This is probably the same problem as in 648 (masterbugs). - The system builds fine on our Sun3 (also M68k) and doesn't core dump on large integers. Status: obsolete ---------------------------------------------------------------------- Number: 649 Title: too strong optimization of datatype constructor (same as 642) Keywords: types, datatypes, representation Submitter: Pierre Cregut Date: 9/22/92 Version: 0.89 Severity: critical Problem: Printing simple datatype value causes "Compiler bug: constant datacon in decon". Code: datatype dt = a of int | b of unit; (* a is necessary *) b (); Transcript: datatype dt con a : int -> dt con b : unit -> dt val it = b Error: Compiler bug: constant datacon in decon Another version is that a piece of code is not executed if it is an argument of such a constructor. ---------------------------------------------------- - (b (print "aa\n") ; ()); val it = () : unit Comment: That is what happened in sourcegroup. To make connections, sourcegroup parse the file The toplevel rule is of type unit so a constructor " interdec of unit " is associated (interdec is the name of the rule). Because of the too strong optimization, the body of the rule that updates the tables by side effect is never executed, so source group never hears about the structures contained in the files it looks at. Status: fixed in 0.91 (Shao) ---------------------------------------------------------------------- Number: 650 Title: Real.realfloor has wrong type Keywords: floats, realfloor Submitter: John Reppy Date: 9/27/92 Version: 0.90 Severity: minor Problem: Isn't realfloor supposed to have type real -> real? Transcript: Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - Real.realfloor; val it = fn : 'a -> 'b Fix: obvious Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 651 Title: System.Directory.cd fails on numbers as directory names Keywords: System, directory Submitter: Konrad Slind Date: 9/28/92 Version: 0.90 System: MIPS/RISCos 4.52 Severity: major Problem: System.Directory.cd doesn't seem to recognize numbers as possible directory names: Transcript: $ mkdir 7 $ sml Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - System.Directory.cd "7"; uncaught exception NotDirectory - Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 652 Title: Compiler bug: contmap enterv 123 building HOL Keywords: contmap Submitter: elsa elsa@research.att.com Date: 9/27/92 Version: 90, 91a System: MIPS & SPARC, UNIX Severity: critical Problem: compiler quits with Compiler bug: contmap enterv 123 Comment: [Elsa Gunter, 9/29/92] I spent some time last night removing the HOL code from the example. Below is a mimimal example that causes the problem. Along my descent I found that the process of elimination was VERY NON-monotonic. At some time during the elimination process I had if true then 2 else 2 which could note be replaced by 2 without the bug going away. However, after removing some other aspects, the if_then_else was no longer necessary. At some point, the length of the string in the exception being handled made a difference, but now it only matters that there is a string. There were other fluxuations as well. I'm afraid I left them on my machine at home, but if you need them, I can try to bring them in tomorrow. This is very possibly not the only minimal code that causes this bug. I found that exceptions A and B must be different, that the one being handled needed to take a record with at least one field having string type and that that field had have a match against a string, i.e., not a wild-card. Code: (* File: bug-652.sml *) exception A exception B of int*string val _ = (raise A) handle B (_,"") => 2 (* end of file *) Transcript: shadow% sml Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - use "bug-652.sml"; Error: Compiler bug: contmap enterv 123 [closing bug-652.sml] - exception A; exception A - exception B of int*string; exception B - val _ = (raise A) handle B (_,"") => 2; Error: Compiler bug: CoreInfo.coreLty3 Another variation of the bug, still present in 91b: Code: (* File: bug.sml *)` structure C = struct exception A exception B of int * string val C = (raise A) handle B (_,"") => 2 end Transcript: hunny% sml Standard ML of New Jersey, Version 0.91a, October 1, 1992 val it = () : unit - use "bug.sml"; Error: Compiler bug: contmap enterv 123 [closing bug.sml] - Another variation: (from Sheard at ogi) - exception foo; - fun bar x = raise foo; Error: Compiler bug: CoreInfo.coreLty3 Comments: This is a variation on bug 652. If you unwrap the code from within the structure then things work. However it still bombs if the code is all inside a structure. Comments: Konrad says that the problem was in 88 as well. Comments: [Zhong Shao, 10/6/92] The compiler bug: contmap enterv 123 has been there for a long long time. Though previously, it occurs as a compiler bug: MipsCM.select: bad dst. These are caused by meaningless cps expressions such as SELECT(INT 0,1,v,...) , APP(INT 0, ...) which are produced by the constant folding optimization on data constructors and exception constructors. A short but temporary fix is to let contmap.sml not check the validity of these expressions and let each target code generator generate some code for SELECT(INT 0,1,v,...). Ideally this should be fixed by letting the SELECT in Lambda and CPS depend on the auxiliary variable generated in each branch and switch statement, and controlling the constant-folding on SELECT. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 653 Title: VECTOR signature isn't pervasive (unlike ARRAY) Keywords: signatures, top level, pervasives Submitter: Cliff Krumvieda (cliff@cs.cornell.edu) Date: 9/30/92 Version: 0.90 System: all Severity: minor Problem: VECTOR signature isn't pervasive (unlike ARRAY) Code: Transcript: Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - signature A = ARRAY; signature A = sig type 'a array exception Size exception Subscript val array : int * '1a -> '1a array val arrayoflist : '1a list -> '1a array val length : 'a array -> int val sub : 'a array * int -> 'a val tabulate : int * (int -> '1a) -> '1a array val update : 'a array * int * 'a -> unit end - signature V = VECTOR; std_in:3.15-3.20 Error: VECTOR undefined (parser) std_in:3.15-3.20 Error: unbound signature: VECTOR Comments: Fix: add VECTOR to boot environment Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 654 Title: System.Directory.cd fails on valid pathnames (same as 651) Keywords: System, directory Submitter: Elsa L. Gunter, elsa@resaerch.att.com Date: 10/1/92 Version: 90 (although I haven't tried earlier) System: Sparc, SunOS (although I haven't tried others) Severity: major Problem: strings from execute don't mix with System.Directory.cd (or not all strings are ccreated equal) Code: The following can cause problems when loaded with use, but more reliably causes problems when entered interactively, or so I've found. fun strip_newline (str) = substring (str, 0, size(str) - 1); fun cwd () = strip_newline (input_line ((fn (x,_) => x) (execute ("/bin/pwd",[])))); val src_dir = cwd (); val tmp = "/base/elsa/working/hol92/hol90.v5/src"; val t = (tmp = src_dir); val _ = System.Directory.cd src_dir; val _ = System.Directory.cd tmp; val _ = System.Directory.cd (src_dir ^ "/.."); val _ = System.Directory.cd src_dir; Transcript: tiree% sml Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - fun strip_newline (str) = substring (str, 0, size(str) - 1); val strip_newline = fn : string -> string - fun cwd () = strip_newline (input_line ((fn (x,_) => x) (execute ("/bin/pwd",[])))); = val cwd = fn : unit -> string - val src_dir = cwd (); val src_dir = "/base/elsa/working/hol92/hol90.v5/src" : string - val tmp = "/base/elsa/working/hol92/hol90.v5/src"; val tmp = "/base/elsa/working/hol92/hol90.v5/src" : string - val t = (tmp = src_dir); val t = true : bool - val _ = System.Directory.cd src_dir; uncaught exception NotDirectory - val _ = System.Directory.cd tmp; - val _ = System.Directory.cd (src_dir ^ "/.."); - val _ = System.Directory.cd src_dir; uncaught exception NotDirectory - Comments: -- The problem is intermittent; the same code seems to behave differently on the same machine under similar circumstances. -- Strings that are entered by hand, or are built by sml processes, such as concatenation seem not to cause the problem. Only strings created by execute (and input_line) seem to cause it. -- I haven't been able to reproduce it just now, but it I recollect that multiple executions of the same coomand (namely System.Directory.cd src_dir; without src_dir being rebound in between) could succeed for a while and then fail. Fix: add "\000" to pathnames Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 655 Title: Compiling Isabelle-92 generates a bus error Keywords: sparc, bus error Submitter: Lal George Date: 10/4/92 Version: 0.88, 0.91a (0.89, 0.90 expose the CoreLty3 bug) System: SPARC and MIPSEB Severity: critical Problem: Generates a bus error(coredump) during compilation. Code: I haven't tried to narrow the code down yet, however, at Bell Labs the following is sufficient to expose the bug: cd /usr/local/sml/isabelle-92/92/Pure Under SML: app use ["NJ.ML","ROOT.ML"]; Transcript: <... lots of stuff deleted ...> structure Earley : PARSER structure TypeExt : TYPE_EXT structure SExtension : SEXTENSION structure Pretty : PRETTY structure Printer : PRINTER Bus error(coredump) Code: [dbm, 10/10/92: following causes bus error in 91a] structure A = struct end; signature S = sig local open A in (* this must be present *) val x : unit (* must have second value beside f, either before or after *) val f: unit -> unit end end; structure B : S = (* must be constrained by S *) struct val x = () fun f() = () end; val _ = B.f(); (* causes Bus error *) Comment: [dbm] It's clear that the bug is called by the local spec form. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 656 Title: Excessive dead code Keywords: code generation, dead code Submitter: Lal George Date: 10/5/92 Version: 0.90 System: SPARC Severity: major Problem: Lot of dead code left around. Code: structure X = struct (* fold function "f" over the sublists of "(x::xs)" of size "n", starting with value "r", and appending "p" to each sublist *) fun folds_onto([],_,r,p,f) = r | folds_onto(x::xs,1,r,p,f) = folds_onto(xs,1,f(r,x::p),p,f) | folds_onto(x::xs,n,r,p,f) = folds_onto(xs,n, folds_onto(xs,n-1,r,x::p,f), p,f) val l = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] val n = 10 fun doit() = folds_onto(l,n,0,[],fn (total,l) => total+length(l)) end Transcript: Toggling the Control.saveLvarNames, and CG.printit flags, a partial output from cpsopt is shown below: (arrows point to dead code) ... folds_onto12224(12238,n12239,r12240,p12241,f12242,12124) = if boxed(12238) [12135] then 12238.0 -> x12136 12238.1 -> xs12137 if ineq((I)1,n12239) [12169] then 12150(12226) = --> {xs12137,n12239,12226,p12241,f12242} -> 12152 folds_onto12224(xs12137,n12239,12226,p12241,f12242,12124) -(n12239,(I)1) -> 12153 {x12136,p12241} -> 12154 --> {xs12137,12153,r12240,12154,f12242} -> 12155 folds_onto12224(xs12137,12153,r12240,12154,f12242,12150) else 12164(12228) = --> {xs12137,(I)1,12228,p12241,f12242} -> 12166 folds_onto12224(xs12137,(I)1,12228,p12241,f12242,12124) {x12136,p12241} -> 12167 {r12240,12167} -> 12168 f12242(12168,12164) else 12124(r12240) {(I)20,(I)0} -> 12174 {(I)19,12174} -> 12175 {(I)18,12175} -> 12176 ... Comment: I know that several rounds of contract are done on this fragment, and the dead code exists after each round. For some mysterious reason, code in cps/contract, that should remove this, does not seem to work. Andrew Says: This is because System.Control.CG.reducemore is 15, which causes cpsopt to give up early when it sees diminishing returns. For documentation that this is a good idea, see Compiling with Continuations, figure 15.11, page 192. Status: not a bug. ---------------------------------------------------------------------- Number: 657 Title: vector values not prettyprinted Keywords: vectors, printing, top level Date: 10/12/92 Version: 0.91c System: all Severity: minor Problem: new pretty printing code doesn't handle vectors Code: Transcript: Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - #[1,2,3]; val it = #[1,2,3] : int vector Standard ML of New Jersey, Version 0.91c, October 12, 1992 val it = () : unit - #[1,2,3]; val it = prim? : int vector Status: fixed in 0.92 ---------------------------------------------------------------------- Number: 658 Title: Compiler bug: PrintVal.switch: none of the datacons matched Keywords: printing, datatypes Submitter: John Reppy Date: 10/13/92 Version: 0.91c System: SPARC 2, SunOS 4.0.1 Severity: critical Problem: Compiler bug: PrintVal.switch: none of the datacons matched caused by Format.compileFormat Transcript: - Format.compileFormat "x = %d"; Error: Compiler bug: PrintVal.switch: none of the datacons matched Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 659 Title: uncaught exception SpillFreemap in closure profiling Keywords: code generation, closure profiling Submitter: Zhong Shao Date: 10/12/92 Version: from 0.86 - 0.90 System: mips Severity: minor Problem: uncaught exception SpillFreemap in closure profiling Code: (* bug.sml *) structure S = struct val a = fn x => x val b = fn x => x val c = fn x => x val d = fn x => x val e = fn x => x val f = fn x => x val g = fn x => x val h = fn x => x val i = fn x => x val j = fn x => x end Transcript: haven% sml Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - System.Control.CG.allocprof := true; val it = () : unit - use "bug.sml"; [closing src/bug.sml] uncaught exception SpillFreemap - Comments: in cps/spill.sml, the instrumenting code for profiling spill records are inserted at the wrong place. Status: fixed in 0.91 ---------------------------------------------------------------------- Number: 660 Title: signals in background sml Keywords: signals Submitter: Doug McIlroy (doug@research.att.com) Date: 10/22/92 Version: 0.90 System: all Severity: major for non-interactive programs Problem: the inherited signal handler state of the SML process is getting trashed. This means that an SML program running in the background still receives signals, even though the shell has disabled them. Fix: The fix will take a bit of work, since the responsibility for signal handling is spread throughout the system. We will have to make the signal handler state (enabled, default, ignored) more visible at the System.Signals level, and the top-level loop and other initialization code will have to check for ignored signals when setting the default handlers. (JHR) Comment: [dbm] probably obsolete Owner: John Status: fixed in 109.21 [new runtime] ---------------------------------------------------------------------- Number: 661 Title: prettyprinter -- Compiler bug: PPTable.install_pp Keywords: prettyprint Submitter: Lal George Date: 10/28/92 Version: 0.91 System: all Severity: minor Problem: install_pp incorrectly raises a compiler bug message Code: val _ = System.PrettyPrint.install_pp ["foo","bar"] Array.update Transcript: Error: unbound structure foo in path foo.bar Error: Compiler bug: PPTable.install_pp Comments: The first error message is also printed with an additional blank space. Fix: In file print/pptable and function install_pp, replace: | _ => ErrorMsg.impossible "PPTable.install_pp" with | _ => ErrorMsg.complain "install_pp: Malformed path" May as well do the same thing with fun make_path. [dbm] Used ErrorMsg.errorNoFile for this and make_path -- no more calls of ErrorMsg.impossible in pptable.sml. Status: fixed in 0.92 (dbm) ---------------------------------------------------------------------- Number: 662 Title: delayed interrupt on MIPS Keywords: signals, mips Submitter: Dave MacQueen Date: 10/28/92 Version: 0.91 System: MIPS/RISCOS 4.52 Severity: minor Problem: Typing the interrupt character (e.g. ^C) doesn't interrupt sml until after a newline is typed. Comments: This could be fixed, but the piping into sml would hang under csh. This is really a RISCos bug. Status: not a bug (ours) ---------------------------------------------------------------------- Number: 663 Title: gc loop on illegal character Keywords: garbage collection, top level Submitter: Lal George Date: 10/28/92 Version: 0.91 System: SPARC, MIPS Severity: major Problem: Typing an illegal character (e.g. ^H) at top level causes an infinite gc loop after the illegal character message. Fix: [Lal George] The fix is to generate ml.lex.sml with a version of lexgen.sml that has the latest bug fixes. The one on /usr/local/sml/bin/sparc does fine. Status: fixed in 0.92a ---------------------------------------------------------------------- Number: 664 Title: installing on Sony RISC NEWS Keywords: Sony News, install Submitter: KONO Shinji Date: 11/4/92 Version: 0.75 System: Sony RISC NEWS, NEWS-OS Release 4.1R Severity: minor Problem: Installation Code: makeml -mips news Transcript: EXC_OV and cache clear system call are machine dependent Comments: I'm afraid this type of mahcine is not famous in U.S. But I'm sure it is used in Japan... Fix: Diffs are appended.. -------- Shinji Kono kono@csl.sony.jp Sony Computer Science Laboratory, Inc. diff -c ./makeml /site/unicorn/export/src/Language/sml-0.75/src/makeml *** ./makeml Wed Nov 4 15:35:55 1992 --- /site/unicorn/export/src/Language/sml-0.75/src/makeml Tue Sep 8 09:55:11 1992 *************** *** 129,135 **** ENDIAN=Big case $1 in riscos) OPSYS=RISCos; CFL="$CFL -systype bsd43" ;; - news) OPSYS=BSD;; mach) OPSYS=MACH; DEFS="$DEFS -DBSD" ;; *) echo "$CMD must specify opsys arg for MIPS (riscos or mach)" --- 129,134 ---- *** runtime/MIPS.dep.c Wed Nov 4 16:28:06 1992 --- /site/unicorn/export/src/Language/sml-0.75/src/runtime/MIPS.dep.c Tue Sep 8 09:54:00 1992 *************** *** 5,18 **** * MIPS dependent code for SML/NJ runtime kernel. */ - #ifdef sony_news - #include /* for EXC_OV */ - #else #ifndef SGI #include /* for EXC_OV */ #else #include /* for EXC_OV */ - #endif #endif #ifndef SGI #include --- 5,14 ---- diff -c runtime/exncode.c /site/unicorn/export/src/Language/sml-0.75/src/runtime/exncode.c *** runtime/exncode.c Wed Nov 4 16:27:33 1992 --- /site/unicorn/export/src/Language/sml-0.75/src/runtime/exncode.c Tue Sep 8 09:54:03 1992 *************** *** 6,19 **** */ #ifdef MIPS - #ifdef sony_news - #include /* for EXC_OV */ - #else #ifndef SGI #include /* for EXC_OV */ #else #include /* for EXC_OV */ - #endif #endif #endif #include --- 6,15 ---- diff -c runtime/ml_os.h /site/unicorn/export/src/Language/sml-0.75/src/runtime/ml_os.h *** runtime/ml_os.h Wed Nov 4 16:47:12 1992 --- /site/unicorn/export/src/Language/sml-0.75/src/runtime/ml_os.h Tue Sep 8 09:54:05 1992 *************** *** 94,106 **** /* cache-flushing stuff */ #if defined(MIPS) - #ifdef sony_news - #include - # define FlushICache(addr, size) \ - sysnews(NEWS_CACHEFLUSH, addr, size, FLUSH_ICACHE) - /* SYS_sysnews will be defined in syscall.h, in OS 4.1 */ - #undef SYS_sysnews - #else #ifndef MACH #include #endif --- 94,99 ---- *************** *** 117,122 **** --- 110,116 ---- # define FlushICache(addr, size) \ (syscall(SYS_sysmips, MIPS_CACHEFLUSH, (addr), (size), ICACHE, 0)) # endif + #else #ifdef NeXT # define FlushICache(addr, size) asm ("trap #2") #else *************** *** 123,129 **** # define FlushICache(addr, size) #endif #endif - #endif #if defined(MACH) && defined(MIPS) --- 117,122 ---- *************** *** 139,145 **** #endif /* where to find syscall.h, used for getting the #define SYS_open */ ! #if defined(VAX) || defined(NeXT) || defined(MORE) || defined(sony_news) #include #else #ifndef SGI --- 132,138 ---- #endif /* where to find syscall.h, used for getting the #define SYS_open */ ! #if defined(VAX) || defined(NeXT) || defined(MORE) #include #else #ifndef SGI Status: obsolete ---------------------------------------------------------------------- Number: 665 Title: Compiler bug: getSymbols on opening nonexistent structures. Keywords: error recovery Submitter: Pierre Cregut Date: 11/5/92 Version: 0.91, 0.92a Severity: minor Problem: Compiler bug: getSymbols on opening nonexistent structures. Transcript: Standard ML of New Jersey, Version 0.92a, November 2, 1992 val it = () : unit - open A; std_in:2.1-2.6 Error: unbound structure A Error: Compiler bug: getSymbols Fix: add ERROR_STR case to getSymbols function in elabstr.sml. Status: fixed in 0.92 (dbm) ---------------------------------------------------------------------- Number: 666 Title: top-level printout on open declarations Keywords: open, printing, top level Submitter: John Reppy Date: 11/6/92 Version: 0.91 Severity: minor Problem: When opening a structure, the bound datatypes don't get printed. Transcript: - structure Foo = struct datatype t = A | B val x = A end; structure Foo : sig datatype t con A : t con B : t val x : t end - open Foo; open Foo val x = A : t - Comments: In fact, only dynamic components are printed, since only they are rebound in the top-level environment (to simplify stale-lvars cleanup). Fix: Change printing of open declarations. Owner: Status: open ---------------------------------------------------------------------- Number: 667 Title: Compiler bug: getvars(STRdec)/fn opening a structure Keywords: modules, functors, printing Submitter: Thomas Yan, tyan@cs.cornell.edu Date: 11/10/92 Version: 0.91 Severity: minor, but potentially very annoying Problem: ? pretty printing a structure created by functor application ? Code: functor A(type aa) = struct type a = aa list val a =[] end structure A = A(type aa = int) open A Transcript: Error: Compiler bug: getvars(STRdec)/fn Fix: ignore special name "" in elabDecl/makeDecl. Status: fixed in 0.92 (dbm) ----------------------------------------------------------------------- Number: 668 Title: missing info in syntax error messages Keywords: error messages, syntax, parsing Submitter: Lal George Date: 11/13/92 Version: 0.92c Severity: major Problem: Some information has been lost from syntax error messages. Transcript: (bug103.sml) {999} -----------------------diff new old ---------------------- diff tsml.tmp /usr/local/sml/testing/bugs/outputs/bug103.out 2,3c2 < std_in:8.5 Error: syntax error < --- > std_in:8.5 Error: syntax error found at RBRACE Comments: The "found at" part of the message is missing from the new mlyacc/base.sml supplied by Tarditi. Fix: This was a non-error-correcting version of base.sml that was inadvertently left in the mlyacc directory sent by Tarditi. The fix was to build and install the error-correcting version of base.sml. Status: fixed in 0.92c ---------------------------------------------------------------------- Number: 669 Title: redundant rule added in some matches Keywords: matches Submitter: Dave MacQueen Date: 11/16/92 Version: 0.92c Severity: major Problem: A rule is added to raise the match exception (and save a location message) in cases where it is redundant. Code: Transcript: - fun f(s,w) = f s w; std_in:0.0-0.0 Error: pattern and expression in val rec dec don't agree (circularity) pattern: 'Z -> 'Y -> 'X expression: 'Z * 'Y -> 'X in declaration: f = (fn (s,w) => w | _ => ( := ; raise )) <==== redundent rule Fix: Caused by switch to prettyprinter for absyn. Left out call of trim to trim last default rule when printing match in CASEexp and FNexp. Status: fixed in 0.92 (dbm) ---------------------------------------------------------------------- Number: 670 Title: missing indicators in redundant match warning messages Keywords: matches, error messages Submitter: Dave MacQueen Date: 11/16/92 Version: 0.88 through 0.92c Severity: major Problem: In version 0.87 and earlier an arrow "-->" was printed in front of redundant rules in the warning message for redundant matches. Code: (in file bug670.sml) fun f (true,x) = 0 | f (true,nil) = 1 | f (false, x) = 2 | f w = 3; Transcript: Standard ML of New Jersey, Version 0.87, July 31, 1992 val it = () : unit - use "bug670.sml"; bug670.sml:1.1-4.11 Warning: redundant patterns in match (true,x) => ... --> (true,nil) => ... (false,x) => ... --> w => ... val f = fn : bool * 'a list -> int Standard ML of New Jersey, Version 0.92b, November 11, 1992 val it = () : unit - use "bug670.sml"; [opening bug670.sml] bug670.sml:1.1-4.11 Warning: redundant patterns in match (true,x) => ... (true,nil) => ... (false,x) => ... w => ... val f = fn : bool * 'a list -> int Comments: I think that 0.88 was the version that incorporated Bill Aitken's rewrite of the match compiler, so it is probably caused by that change. Fix: added a rev around call of fixupUnused in doMatchCompile in translate/mc.sml. fixupUnused was returning a list of ints sorted in the wrong order. Status: fixed in 0.92 (dbm) ---------------------------------------------------------------------- Number: 671 Title: visibility of parameter in functor signature Keywords: modules, functors, scope Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 11/17/92 Version: 0.91 System: all Severity: major Problem: unbound structure in functor signature definitions Code: (* case 1 *) funsig FSIG(B : sig type t end) = sig val f : B.t end (* case 2 *) funsig FSIG(structure B : sig type t end) = sig val f : B.t end (* case 3 *) funsig FSIG(B : sig type t end) = sig val f : t end (* case 4 *) funsig FSIG(structure B : sig type t end) = sig val f : t end Transcript: haven% sml Standard ML of New Jersey, Version 0.91, October 26, 1992 val it = () : unit - funsig FSIG(B : sig type t end) = sig val f : B.t end; std_in:2.47-2.49 Error: unbound structure B in path B.t - funsig FSIG(structure B : sig type t end) = sig val f : B.t end; std_in:0.0-0.0 Error: unbound structure B in path B.t - funsig FSIG(B : sig type t end) = sig val f : t end; funsig FSIG(B:) = sig val f : ..t end - funsig FSIG(structure B : sig type t end) = sig val f : t end; std_in:2.57 Error: unbound type constructor t Comments: The code for case 1 and 2 should be valid, as they are in 89. The code for case 3 and 4 should be rejected (intuitively) Fix: Here is the fix for the bug in signatures of functors: tulipe-cregut->diff elabsig.sml elabsig.sml~ 539,540c539,540 < of (NONE,_) => Normalize.openX(name_X,sgnArg,symtotalParent) < | (SOME _ ,_) => --- > of (SOME _,_) => Normalize.openX(name_X,sgnArg,symtotalParent) > | (NONE,_) => It is just a stupid inversion... Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 672 Title: start() in i386 Mach Keywords: x86 Submitter: Mark Leone (mleone@cs.cmu.edu) Date: 11/18/92 Version: 0.91 System: i386 Mach Severity: minor Problem: start() is now _start() in i386 Mach. Comments: I386.prim.s used to require an #ifdef for Mach to set startptr to start(), not _start(). This is no longer necessary. Fix: *** I386.prim.s.orig Wed Nov 18 13:25:23 1992 --- I386.prim.s Wed Nov 18 13:24:13 1992 *************** *** 651,658 **** /* this bogosity is for export.c */ .globl _startptr _startptr: - #if defined(I386) && defined(MACH) - .long _start - #else .long start - #endif --- 651,654 ---- Status: fixed in 0.92 ---------------------------------------------------------------------- Number: 673 Title: failure of type propagation with higher-order functors Keywords: modules, functors, higher-order functors Submitter: Dave MacQueen Date: 11/20/92 Version: 0.92 Severity: major Problem: Type information is not propagated through application of a parameter functor. Code: (bug673.sml) signature MONOID = sig type t val plus: t*t -> t val e: t end; (* functor signature declaration *) funsig PROD (structure M: MONOID structure N: MONOID) = MONOID functor Square(structure X: MONOID functor Prod: PROD): MONOID = Prod(structure M = X structure N = X); functor Prod(structure M: MONOID structure N: MONOID): MONOID = struct type t = M.t * N.t val e = (M.e, N.e) fun plus((m1,n1),(m2,n2))=(M.plus(m1,m2),N.plus(n1,n2)) end; structure Int = struct type t = int val e = 0 val plus = (op +): int*int -> int end; structure Int2 = Square( structure X = Int functor Prod = Prod); #1(Int2.e); Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - use "bug673.sml"; [opening bug673.sml] signature MONOID = sig type t val plus : t * t -> t val e : t end funsig PROD(:) = sig type t val plus : t * t -> t val e : t end functor Square : functor Prod : structure Int : sig eqtype t val e : int val plus : int * int -> int end structure Int2 : MONOID bug673.sml:39.1-39.10 Error: operator and operand don't agree (type mismatch) operator domain: {1:'Y, '...Z} operand: Int2.t in expression: (fn {1=1,...} => 1) (e) [closing bug673.sml] - Fix: [Cregut] diff elaborate/elabstr.sml elaborate/elabstr.sml~ 525,528c525,528 < fun computeSelf (StructStr _) = true < | computeSelf (MarkStr(def,_,_)) = computeSelf def < | computeSelf _ = false < val self = computeSelf def --- > val self = > (case def of VarStr _ => false > | MarkStr(VarStr _,_,_) => false > | _ => true) Ok I think it fixes the problem: match thought that it could suppress its origin whereas it was a computed application to be done at each functor application. In the bogus version you could correct the problem - by suppressing the signature MONOID - by putting an intermediate level of structure so that the optimisation of self was irrelevant (which is a kind of bug but we have already talked about it) (an intermediate level = functor Square(,,,) = struct structure result = Prod(...) end; ) Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 674 Title: System.Env.filterEnv raises exception IntmapF Keywords: environment, filterEnv Submitter: Dave MacQueen Date: 11/22/92 Version: 0.92 Severity: major Problem: System.Env.filterEnv raises exception IntmapF. Transcript: - System.Env.filterEnv(!System.Env.pervasiveEnvRef,[System.Symbol.valSymbol "hd"]); uncaught exception IntmapF Comments: Probably related to bug 640. Fix: fix lvarOfBinding in modules/moduleutil.sml Status: fixed in 0.93a (dbm) ---------------------------------------------------------------------- Number: 675 Title: prettyprinter doesn't sense System.Print.linewidth Keywords: printing, prettyprint Submitter: Konrad Slind Date: 11/23/92 Version: 0.92 Severity: major Problem: System.Print.linewidth doesn't seem to control the linewidth used by the system prettyprinter. Transcript: $ sml Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - System.Print.printLength := 10000; val it = () : unit - val L = ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa"]; val L = ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd", "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa", "adsfasd","afasdfa","adsfasd","afasdfa"] : string list - System.Print.linewidth := 20; val it = () : unit - L; val it = ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd", "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa", "adsfasd","afasdfa","adsfasd","afasdfa"] : string list - System.Print.linewidth := 150; val it = () : unit - L; val it = ["adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd", "afasdfa","adsfasd","afasdfa","adsfasd","afasdfa","adsfasd","afasdfa", "adsfasd","afasdfa","adsfasd","afasdfa"] : string list - Comment [Slind, 7/20/93] Last fall, I reported a bug in System.Print.linewidth, namely that the system prettyprinter wouldn't track changes to this variable. It seems to be a bug arising out of bootstrapping. Now, I haven't found the bug, but I do have a bit more information about it: changes to this variable do get tracked in the environment used by "use_stream". Example. - val eval_string = System.Compile.use_stream o open_string; val it = fn : string -> unit - System.Print.linewidth; val it = ref 79 : int ref - System.Print.linewidth := 30; val it = () : unit (* Std. top level environment, value of "linewidth" ignored. *) - [12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12]; val it = [12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12] : int list (* Change gets tracked. *) - eval_string "[12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12,12]"; val it = [12,12,12,12,12,12,12,12,12, 12,12,12,12,12,12,12,12,12, 12,12] : int list val it = () : unit Owner: dbm Status: open ---------------------------------------------------------------------- Number: 676 Title: Out of order record field evaluation. Keywords: records, evaluation Submitter: Andrew Appel Date: 11/24/92 Version: 0.92 Severity: Critical Problem: Out of order record field evaluation. Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - val r = ref 0; val r = ref 0 : int ref - fun g() = (inc r; !r); val g = fn : unit -> int - {last=g(),first=g()}; val it = {first=1,last=2} : {first:int, last:int} Status: fixed in 0.93 (Zhong Shao) ---------------------------------------------------------------------- Number: 677 Title: memory leak Keywords: space leak Submitter: Kjeld H. Mortensen (kjeld@metasoft.com) Date: 11/24/92 Version: 0.92 Systems: Sparc server 330, SunOS 4.1.1, HP9000s400, HPUX 8.0 Severity: Major Problem: Memory leaks (heap grown when not supposed to). Code: Transcript: Comments: I have made experiments with SML/NJ v0.92 in order to see if there were any memory leaks. It seems to me that it is the case. My standard experiment is the same as from bug report #500, which was fixed by v0.82. The bug was present in v0.75 and now in v0.92, but not to the same degree. I've included a bug report in case you think it should be added to the masterbugs list. It is very important for us that the compiler doesn't slow down over a longer period of usage, as a result of memory leaks. So I've given the bug a high priority. Using the compiler over a long period of time where stuff is only evaluated or values "overwritten", the heap size increases unnecessarely (see also bug #500). (v0.92) ----------Mem Size---------- start end end-start ratio softmax slow down Sparc 19968 kb 21096 kb 1128 kb 3 28 Mb 26 % HPs400 11224 kb 11900 kb 676 kb 3 32 Mb 16 % The table shows memory usage (as show by 'ps') at the beginning and end of the experiment, the difference between end and start, ratio and softmax (from System.Control.Runtime), and how much slower the compiler is at the end as compared with the beginning of the experiment. The session lasts 45 and 60 minutes for the HP and Sparc respectively. I want to point out that the earlier version 0.82 doesn't have any detectable memory leak and therefore no slow down. Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 678 Title: emacs tags broken Keywords: emacs Submitter: Charlie Krasic (cckrasic@plg.uwaterloo.ca) Date: 11/24/92 Version: 0.92 System: Sun 670/MP (Sparc) w/SunOS 4.3 (?) Severity: minor Problem: emacs tags broken when trying to create TAGS file for SML/NJ Code: modified the file 'all' to contain directives to toggle indexing and markabsyn, then run smlc < all, then run sml-tags -r. I tried both my old version of sml-tags and a newly built version of sml-tags. Transcript: no transcript. Re-compiling the entire system creates the various .i.xxx tag files. Running "sml-tags -r" gives: uncaught exception getIntError Comments: This precedure works fine if I use a batch compiler based on 0.91 Owner: Status: obsolete ---------------------------------------------------------------------- Number: 679 Title: "Compiler bug: addObject" while compiling the Edinburgh library Keywords: modules, functors, abstype Submitter: wkh@dce.austin.ibm.com (Ward K. Harold) Date: 11/25/92 Version: 0.92 (works up through version 0.82, fails in version 0.83) System: RS6000, AIX 3.2, MIPS, SPARC Severity: major Problem: "Compiler bug: addObject" while compiling the Edinburgh library, version 1.20 or 1.21. Occurs when loading MonoSet.sml in the MonoSet functor. Code: (* simplified version: bug679.sml *) functor F (X: sig end) = (* has to be a functor, not a structure *) struct abstype s = S with type t = unit (* type definition necessary *) end end Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - use "foo.sml"; [opening foo.sml] Error: Compiler bug: addObject [closing foo.sml] - Fix: [Pierre Cregut] When I counted the number of components created in a structure that have a representation in the core, I forgot to count the components coming from the body of an abstype tulipe-cregut->diff elabstr.sml elabstr.sml~ 42,44c42,43 < | (AbstypeDec {abstycs,withtycs,body,...}, t) => < let val (strN,fctN,typN) = count (body,t) < in (strN,fctN,typN+length abstycs+length withtycs) end --- > | (AbstypeDec {abstycs,withtycs,...}, (strN,fctN,typN)) => > (strN,fctN,typN + length abstycs + length withtycs) Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 680 Title: Bad vertical alignment prettyprinting case expression. Keywords: printing, prettyprint Submitter: Dave MacQueen Date: 11/20/92 Version: 0.92 Severity: minor Problem: Bad veritcal allignment prettyprinting case expression. Transcript: - if 2 then 3 else 4; std_in:0.0-0.0 Error: case object and rules don't agree (tycon mismatch) rule domain: bool object: int in expression: (case 2 of true => 3 | false => 4) Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 681 Title: building on SGI Indigos with cc version 3.10 Keywords: install, runtime, mips, SGI Submitter: asgeir@viking.asd.sgi.com (Asgeir Eiriksson), Fernando Pereira Date: 12/2/92 Version: 0.92 System: SGI R3000 and R4000 Indigo Severity: Major Problem: sml fails to build with /usr/bin/cc version 3.10 (the latest) Transcript: cc -O -DMIPS -D_BSD_SIGNALS -D__STDC__ -Dsgi -DSGI -o run run.o run_ml.o callgc.o gc.o export.o timers.o ml_objects.o cfuns.o cstruct.o signal.o exncode.o malloc.o mp.o sync.o prim.o allmo.o /usr/bin/ld: This executable contains branch instruction(s) at end-of-page makeml> echo ( exportML "sml"; output(std_out,System.version); output(std_out,(chr 10)); output(std_out, "")); | runtime/run -m 8192 -r 5 -h 2048 IntMipsBig [Increasing heap to 2051k] [Loading mo/CoreFunc.mo] ... [closing boot/perv.sml] [Loading boot/overloads.sml] structure Overloads : ... [closing boot/overloads.sml] Go for it - [Major collection... 15% used (550960/3548736), 350 msec] [Decreasing heap to 2699k] [Major collection... 100% used (552208/552208), 320 msec] ==> Inconsistent object for export: !(0) uncaught exception Io "exportML "sml": Error 0" - Comments: This does not occur with the 2.10 version of cc. Reproducible on Fernando Pereira's Indigo. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 682 Title: excess newlines in compiler warning message Keywords: printing, error messages Submitter: Thomas Yan tyan@cs.cornell.edu Date: 12/2/92 Version: .92 Severity: minor Problem: extraneous blank lines printed during compilation Code: val [1,2,3] = [1,2,3] Transcript: - val [1,2,3] = [1,2,3]; std_in:55.1-55.21 Warning: binding not exhaustive 1 :: 2 :: 3 :: nil = ... - Comments: baffling the first time it appears Fix: In print/ppdec.sml, make each declaration responsible for printing it's own terminating newline. Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 683 Title: Compiler bug: Extern: update_structure 2 Keywords: modules, signatures, error recovery Submitter: Sanjiva Prasad Date: 12/2/92 Version: 0.92 Severity: minor Problem: Elaborating an illegal signature decl leads to Compiler bug: Extern: update_structure 2. Code: signature S = sig functor Foo(X: S) : S end Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - signature S = = sig = functor Foo(X: S) : S = end; std_in:4.18 Error: unbound signature: S std_in:4.23 Error: unbound signature: S Error: Compiler bug: Extern: update_structure 2 Fix: [Pierre Cregut] update_structure didn't consider the case where an error had already been encountered. I have added two cases: the structure is an error, the signature is an error. Only the second one is proved to be necessary but the first one is safe. tulipe-cregut->diff extern.sml extern.sml~ 102,103d101 < | ERROR_STR => () < | INSTANCE{sign as ERROR_SIG,...} => () Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 684 Title: Compiler bug: checkList Keywords: modules, functors, higher-order functors Submitter: Sanjiva Prasad Date: 12/2/92 Version: 0.92 Severity: major Problem: A functor definition causes "Compiler bug: checkList". Transcript: - signature S1 = sig end; signature S1 = sig end - funsig FOO (X:S1) (Y:S1) = S1; funsig FOO(X:) = sig functor : end - structure A:S1 = struct end; structure A : S1 - functor Bar (C:S1) = C; functor Bar : - functor Foo (X:S1) (Y:S1) = X; functor Foo : - functor Foo:FOO = Foo; functor Foo : - funsig FOO2 (X:S1) = S1; funsig FOO2(X:) = sig end - functor Dummy (W: sig functor F :FOO2) (functor Z:FOO2) = Z(A); std_in:9.38 Error: syntax error found at RPAREN - functor Dummy (W: sig functor F :FOO2 end ) (functor Z:FOO2) = Z(A); functor Dummy : - functor Bar1 = Dummy (Foo(A)) (functor Z = Bar); std_in:10.16-10.47 Error: unmatched structure spec: F std_in:10.16-10.47 Error: unbound functor: in path . - functor Dummy (W: S1) (functor Z:FOO2) = Z(A); functor Dummy : - functor Bar1 = Dummy (Foo(A)) (functor Z = Bar); std_in:11.16-11.47 Error: unbound functor: in path . - structure C:S1 = struct functor G=Bar end; structure C : S1 - open C; open C - structure C:S1 = Foo(A); structure C : S1 - open C; open C - funsig ARBIT (B:S1) (type t) = S1; funsig ARBIT(B:) = sig functor : end - - - functor Bar5 = Foo (Foo A); std_in:18.25 Error: syntax error found at ID - functor Bar5 = Foo (Foo (A) ); Error: Compiler bug: checkList Code: (* bug684.sml *) (* the following reproduces the bug in 0.92 *) signature S = sig end; funsig FOO (X:S) (Y:S) = S; functor Foo (X:S) (Y:S) = X; functor Foo: FOO = Foo; (* with this deleted produces different strange error *) structure A:S = struct end; structure C:S = Foo(A); (* with this deleted, no error *) functor Bar5 = Foo(Foo(A)); (* ===> Error: Compiler bug: checkList *) Comments: Currently one must view all arguments to a functor as structures. In particular, if an argument to a H-O functor is itself a functor, it is viewed as being a functor component of a structure argument. But suddenly here, I found some funny behaviour when trying to treat results of part-applying curried functors as structures. I've attached the session transcript. The symptoms were repeated when I replayed the session script in toto. But when I tried to redo things with some of the chaff (irrelevant definitions and evaluations) removed, things worked fine. The Compiler bug checkList was a surprise. Status: fixed in 0.93 (probably same as 673) ---------------------------------------------------------------------- Number: 685 Title: loss of line numbers loading with System.Compile Keywords: line numbers, top level Submitter: Gene Rollins Date: 12/3/92 Version: 0.92 Severity: minor Problem: Code loaded into the interactive system using System.Compile does not give accurate line numbers when using System.Compile rather than use. Code: structure c :sig val c :string -> unit end = struct open System.Env System.Compile fun withSource (sourceName:string) (action :source -> 'a -> 'b) (argument:'a) :'b = let val sourceStream = open_in sourceName val source = makeSource (sourceName, 1, sourceStream, false, {linewidth= !System.Print.linewidth, flush=System.Print.flush, consumer=System.Print.say}) val result = action source argument handle exn => (closeSource source; raise exn) in closeSource source; result end fun c (sourceName:string) :unit = let val env = layerEnv (!topLevelEnvRef, !pervasiveEnvRef) val se = staticPart env fun comp source () = compile (source, se) val compUnit = withSource sourceName comp () in () end end ********** a.sml ******* structure a = struct fun f [] = () end ************************ See the difference with: - c.c "a.sml"; - use "a.sml"; Fix: In elaborate/frontend.sml, make parse smash linePos only for interactive source. Also fixed it so that compileAst can take an optional source parameter so linenumbers can be provided in error messages for elaborating and translating asts. (build/compile.sml, boot/system.sig) Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 686 Title: floating-point divide by zero is broken on SGI Keywords: Submitter: D. A. Ladd (ladd@graceland.ih.att.com) Date: 11/30/92 Version: 0.91, 0.92 System: SGI Severity: major Problem: floating-point divide by zero is broken Code: 1.0 / 0.0; Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - 1.0 / 0.0; strange floating point error, 14 Comments: This works okay on other MIPS-based machines (e.g., hunny). Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 687 Title: src/Makefile is out of date. Keywords: install, Makefile Submitter: Fernando Pereira Date: 12/4/92 Version: 0.92 Severity: major Problem: src/Makefile is out of date. First of all, the Makefile refers to ../tools/sourcegroup but the distribution has SG2.2nj. With this fixed, various files seem to be missing: cat ../tools/gnutags/export.sml | sml-export Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit [opening ../tools/sourcegroup/src/StringXtra.sig] [use failed: open_in "../tools/sourcegroup/src/StringXtra.sig": openf failed, No such file or directory] uncaught exception (Loader): SystemCall Then sml-conn fails to make because ../tools/sourcegroup/sml-conn/export.sml is missing. Finally, sourcegroups fail to build with [opening date.sml] [use failed: open_in "date.sml": openf failed, No such file or directory] [closing ../tools/sourcegroup/save.sml] uncaught exception (Loader): SystemCall Comments: the files required to build smlsg and sml-conn are all there so they can be built manually. (sml-conn/export.sml no longer exists). Fix: get rid of src/Makefile Status: fixed in 0.93 (check) ---------------------------------------------------------------------- Number: 688 Title: profiler doesn't compile Keywords: profiler Submitter: Fernando Pereira Date: 12/5/92 Version: 0.92 Severity: major Problem: Building the profiling version of sml fails while compiling profile/profperv.sml when executing sml < profile/script Transcript: [opening profile/profperv.sml] val it = () : unit profile/profperv.sml:73.17-73.26 Error: operator is not a function operator: bytearray in expression: ba sub profile/profperv.sml:79.18-79.32 Error: operator and operand don't agree (tycon mismatch) operator domain: bytearray operand: (bytearray * int -> int) -> int -> 'Z in expression: length ba profile/profperv.sml:83.16-83.33 Error: operator and operand don't agree (tycon mismatch) operator domain: bytearray operand: (bytearray * int -> int) -> int -> 'Z in expression: length ba profile/profperv.sml:88.29-88.41 Error: operator is not a function operator: bytearray in expression: ba sub [closing profile/profperv.sml] Fix: add "infix 9 sub" just after "open ByteArray", because infixes are no longer carried by structures (signatures?). [ByteArray shouldn't be signature constrained because of inlining!!!] Status: fixed in 0.93a ---------------------------------------------------------------------- Number: 689 Title: Compiling lambda prolog fails with compiler bug "adjust_variable". Keywords: Submitter: Fernando Pereira Date: 12/5/92 Version: 0.92 Severity: Critical Problem: Compiling lambda prolog fails with compiler bug "adjust_variable". Code: elp.tar.Z Transcript: sgiharrar:lp$ sml-export Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - use "export-elp.sml"; .... lots of stuff .... [opening elp/elp_global_program.fun] elp/elp_global_program.fun:23.34-23.70 Error: operator and operand don't agree (type mismatch) operator domain: '2Z * '2Y operand: '2Z * '2Y in expression: ref (imports,program) elp/elp_global_program.fun:23.7-24.26 Error: operator and operand don't agree (type mismatch) operator domain: string * (string list * Program.program) ref operand: string * _ in expression: ModuleState (module_name,ref (imports,program)) elp/elp_global_program.fun:26.10-26.27 Error: operator and operand don't agree (type mismatch) operator domain: string * string operand: string * string in expression: = (module_name,m1) elp/elp_global_program.fun:27.12-27.38 Error: operator and operand don't agree (type mismatch) operator domain: (string list * Program.program) ref * (string list * Program.program) operand: (string list * Program.program) ref * (string list * Program.program) in expression: := (entry,(imports,program)) Error: Compiler bug: adjust_variable [closing elp/elp_global_program.fun] Status: fixed in 0.93 (probably related to bug 673 or 671) ---------------------------------------------------------------------- Number: 690 Title: maskSignals breaks interactive input Keywords: signals, top level Submitter: Andrew Tolmach apt@cs.pdx.edu Date: 12/8/92 Version: 0.92 System: Sun4 SunOS, Sequent, probably others Severity: minor Problem: maskSignals breaks interactive input Code: - System.Signals.maskSignals true; - ^C Transcript: With above code, system goes into infinite loop. Comments: Any signal for which a handler is installed will do in place of CTRL/C. The problem is in cfuns.c/ml_wait_for_in: restart:; /* on EINTR */ if (msp->inSigHandler || ((! _setjmp (msp->SysCallEnv)) && (5) (((msp->ioWaitFlag = 1), (msp->NumPendingSigs == 0))))) { ... (1) select() ... } else { (6) backup_kont(msp); sigsetmask (0); /* re-enable signals */ return; } if (sts == -1) { if (errno == EINTR) (4) backup_kont(msp); else raise_syserror(msp, 0); return; } and its interaction with signal.c/sig_handler: /* record the signal */ (2) msp->NumPendingSigs++; msp->SigTbl[ml_sig]++; (3) if (!msp->maskSignals) { if (msp->ioWaitFlag) { /* We were waiting for a blocking I/O operation when the signal occurred, * so longjmp out of the operation (see io_wait() in "cfuns.c"). */ _l