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"). */ _longjmp (msp->SysCallEnv, 1); } else ... } Suppose we've called maskSignals false, setting msp->maskSignals to true, have called ml_wait_for_in, and are sitting in the select call (line 1) when a signal occurs. The following occurs: 1) The system invokes sig_handler, which increments NumPendingSigs (line 2) but doesn't longjmp out because of the test at line 3. 2) The select call returns EINTR, so ml_wait_for_in calls backup_kont (line 4) to set up the ML state to reenter C immediately. 3) When ml_wait_for_in is reentered, it refuses to recall select because of the test on NumPendingSignals at line 5; instead, it calls backup_kont again (line 6), and returns to C. This step is then repeated forever. Fix: One possiblity is to change the test in line 5 to: (5) (((msp->ioWaitFlag = 1), (msp->NumPendingSigs == 0 || msp->maskSignals))))) { Or, the position of the test against maskSignals could be changed in sigHandler, so that the longjmp is always activated? In that case, EINTR should never be returned, right? Comment [jhr]: I've thought about this, and I think that the correct fix is to check for masked signals in ml_wait_for_in (also in ml_select). In particular. the code should be if (msp->inSigHandler || msp->maskSignals || ...) since being in a signal handler implies masked signals. I would point out that calling maskSignals prior to calling ml_in_wait is bogus, since the whole point of ml_in_wait is to provide a safe place to interrupt when waiting for input. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 691 Title: Compiler bug: ModuleUtil: lookFormalBinding 1 Keywords: modules, functors, higher-order functors Submitter: Pierre Cregut Date: 12/8/92 Version: 0.92 Severity: Major Problem: Compiler bug: ModuleUtil: lookFormalBinding 1 Code: signature S1 = sig type a ; val intro : unit -> a end; functor F4 (structure X1 : S1) (structure X2 : sig val x : X1.a end) = struct end; Comments: But I am afraid there are other changes to make. The bug comes from FULL_SIG found while elaborating the argument of an embedded functor. There are other places where FULL_SIG are created. I will try to eliminate all of them. Fix: Here is a fix: tulipe-cregut->diff elabstr.sml elabstr.sml~ 352,355c352 < binding = < STR_FORMAL{ < pos=0, < spec=signatureOfStructure argument}, --- > binding = STR_FORMAL{pos=0,spec=FULL_SIG}, Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 692 Title: signal handling on 386 can dump core Keywords: signals, x86 Submitter: Andrew Tolmach apt@cs.pdx.edu Date: 12/14/92 Version: 0.90+ System: visible on Sequent; affects all 386 systems Severity: critical Problem: signal handling on 386 can dump core Code: open System.Signals fun alarmHandler(_,k) = k val _ = setHandler(SIGALRM,SOME(alarmHandler)) open System.Timer val setitimer = System.Unsafe.Cinterface.setitimer fun h() = setitimer(0,TIME{sec=0,usec=10000} TIME{sec=0,usec=10000}); (* System can dump core at any time after h() is executed. The following sequence is quite reliable on Sequents: *) val cd = System.Directory.cd; fun r() = let fun f () = (cd "."; f()) in h(); f() end; r(); Comments: The problem is that limitptr lives on the stack and is addressed relative to %esp. Unfortunately, various operations in the 386 implemention (notably saveregs, some fp operations, and all pc-relative loads in generated code) temporarily push things onto the stack, thus altering %esp. But the adjust_limit routine, which zeroes the limitptr, may be executed by command of the signal handler *at any time* when inML == 1; thus the wrong piece of the "ML stack frame" gets zeroed (in this case the exncont). Fix: Add a field MLframe to the ML state vector (for 386's only), pointing to the base of the ML stack frame. This field is initialized by restoreregs before setting inML = 1. The signal handler uses this pointer to access and zero the limit pointer directly, avoiding the need for an adjust_limit routine. [I've sent Lal a bundle containing these changes.] Longer-term fix: If the 386 implementation were cleaned up so that it no longer messed with %esp, use of the MLframe pointer in the signal handler could be replaced by scp->sp. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 693 Title: backspace (rubout char) under HPUX 8.0 Keywords: hppa, hpux, I/O Submitter: M.J.Morley Date: 12/17/92 Version: Version 75, November 11, 1991 System: HP 380/9000 under HP-UX 8.0 Severity: minor bur, major irritation in all ML applications Problem: Backspace incorrectly bound? Comments: This was not manifest under HP-UX 7.0 but when we recently switched to the HP-UX 8.0 the backspace `stopped working'. Characters are rubbed out but this effect is not echoed to the screen. The kit we use is the standard HP config. screen/mouse/KB -- running MIT's X11R4, in case that is significant. Status: not a bug (ours) ---------------------------------------------------------------------- Number: 694 Title: System.Compile.execute provokes compiler bug ModuleComp.getImport Keywords: modules, signatures, signature matching Submitter: Kjeld H. Mortensen (kjeld@metasoft.com) Date: 12/21/92 Version: 0.92 System: Sparc, SunOS 4.1.1 Severity: major Problem: System.Compile.execute provokes ModuleComp.getImport compiler bug msg Code: The file "test.sml" used in the following is just: signature FOO = sig val x : int end; structure foo = struct val x = y end; Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - val y= 0; val y = 0 : int - val myenv= System.Env.concatEnv (!System.Env.topLevelEnvRef, !System.Env.pervasiveEnvRef); val myenv = prim? : environment - val mystatenv= System.Env.staticPart myenv; val mystatenv = prim? : staticEnv - val myppcons= {linewidth= 79, consumer= (fn (x:string) => print x), flush= (fn () => ())}; val myppcons = {consumer=fn,flush=fn,linewidth=79} : {consumer:string -> unit, flush:unit -> unit, linewidth:int} - val mystream= open_in "test.sml"; (* See 'Code' above *) val mystream = - : instream - val mysrc = System.Compile.makeSource ("test.sml", 1, mystream, false, myppcons); val mysrc = prim? : source - val myStatxCode= System.Compile.compile (mysrc, mystatenv); val myStatxCode = ({boundLvars=[10162],staticEnv=prim?},prim?) : System.Compile.staticUnit * codeUnit - val mynewenv= System.Compile.execute (myStatxCode, myenv); Error: Compiler bug: ModuleComp.getImport uncaught exception Compile Comment: [dbm] Free value variables in compilation units are not supported in 0.93. This problem will go away in 0.94. Status: not a bug ---------------------------------------------------------------------- Number: 695 Title: segmentation fault involving System.Ast Keywords: segmentation fault, crash Submitter: Gene Rollins Date: 12/22/92 Version: 0.92 System: Decstation, Mach Severity: critical Problem: segmentation fault Code: structure bug = struct structure A = System.Ast fun ok m = (print ("\n\n"); flush_out std_out) val p1 = "functor G = H" val p2 = "functor F () = struct end" fun try program = let val ppc = {linewidth = !System.Print.linewidth, flush = System.Print.flush, consumer = System.Print.say} val strm = open_string (program ^ "\n") val src = System.Compile.makeSource ("", 1, strm, false, ppc) val start = System.Env.staticPart (!System.Env.pervasiveEnvRef) val (ast, se) = System.Compile.parse (src, start) in do_dec ast handle exn => (close_in strm; raise exn); close_in strm end and do_dec (ast:A.dec) :unit = (case ast of (A.ValDec _) => () | (A.ValrecDec _) => () | (A.FunDec _) => () | (A.TypeDec _) => () | (A.DatatypeDec _) => () | (A.AbstypeDec _) => () | (A.ExceptionDec _) => () | (A.StrDec _) => () | (A.AbsDec _) => () | (A.FctDec (arg:A.fctb list)) => app f_fctb arg | (A.SigDec _) => () | (A.FsigDec _) => () | (A.LocalDec _) => () | (A.SeqDec arg) => app do_dec arg | (A.OpenDec _) => () | (A.OvldDec arg) => () | (A.FixDec arg) => () | (A.ImportDec arg) => () | (A.MarkDec (arg,_,_)) => do_dec arg ) and f_fctb (ast:A.fctb) :unit = (case ast of (A.Fctb {name:symbol, def:A.fctexp}) => f_fctexp def | (A.MarkFctb (arg,_,_)) => f_fctb arg ) and f_fctexp (ast:A.fctexp) :unit = let val _ = ok "0" in case ast of (A.VarFct (path:A.path, constraint:A.fsigexp option)) => let val _ = ok "1" val symbol'list = ((System.Unsafe.cast path) :symbol list) in case path of [] => ok "1a" | (head::tail) => (ok "1b"; System.Symbol.name head; ok "1c") end | (A.FctFct {params :(symbol option * A.sigexp) list, body :A.strexp, constraint :A.sigexp option}) => ok "2" | (A.MarkFct (arg,_,_)) => (ok "3"; f_fctexp arg) end end Transcript: - bug.try bug.p1; (* ok *) - bug.try bug.p2; (* causes segmentation fault *) Comments: If you look at the output, it seems that in the function f_fctexp, the case on the ast should go on the FctFct branch for bug.p2, but it goes on the VarFct branch. When I try to bind the offending ast to a name at the top-level I get: Error: Compiler bug: PPVal.switch: none of the datacons matched Fix: eternalized ast did not agree with internal ast on type fctexp. Status: fixed in 0.93c (dbm) ---------------------------------------------------------------------- Number: 696 Title: Type system error in "includes" of signatures Keywords: modules, signatures, include Submitter: Chet Murthy (murthy@margaux.inria.fr) Date: 12/29/92 Version: 0.92 System: sun4, sunos 4.1 Severity: major Problem: Type system error in "includes" of signatures Code: see transcript Transcript: I just found a bug in signature mechanism of 0.93. It manifests itself when I construct signatures by using "include". I enclose a short file which elicits the bug in the version of 0.93 which I recuperated from research.att.com, around the end of november. P.S. The result of the bug is a bus error. --------------cut here------------------- structure A = struct type (''1a, '1b) t = ((''1a * '1b) list) fun new() = nil fun toList l = l fun dom (l:(''a, 'b) t) = List.map #1 l end signature ASIG = sig type (''1a, '1b) t val new : unit -> (''1a, '1b) t end signature BSIG = sig type (''1a, '1b) t val dom : (''1a, '1b) t -> ''1a list end ; signature AB_SIG = sig include ASIG BSIG end ; structure goo : AB_SIG = A; let val _ = goo.dom (SOME "foo") in 23 end; Fix [Cregut]: tulipe-cregut->diff elabsig.sml elabsig.sml~ 68c68 < fun adjustBinding (basetype,basestr,basefct,baseslot,makeStamp,redef) = --- > fun adjustBinding (basetype,basestr,basefct,baseslot,makeStamp) = 108,112d107 < and relocate pos = < let fun reloc [] = pos+basetype < | reloc ((porig,pdest)::l) = < if pos = porig then pdest else reloc l < in reloc redef end 125c120 < FORMtyc{pos=relocate pos, --- > FORMtyc{pos=pos+basetype, 143c138 < RELtyc {name=name,pos=([],relocate offset)} --- > RELtyc {name=name,pos=([],offset+basetype)} 181c176 < val adjust = adjustBinding (!tycons,!strs,!fcts,!slots,makeStamp,redef) --- > val adjust = adjustBinding (!tycons,!strs,!fcts,!slots,makeStamp) Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 697 Title: wrong Subscript exception in ByteArray Keywords: ByteArray Submitter: Chet Murthy (murthy@margaux.inria.fr) Date: 12/29/92 Version: 0.92 System: Sun4, rel 4.1 Severity: minor Problem: ByteArray.sub and ByteArray.update raise Array.Subscript and not ByteArray.Subscript (otherwise named Ord) Code: let val x = ByteArray.array(10,0) in ByteArray.sub(x,11) end Transcript: Comments: Fix: In translate/inlineops.sml - the change was two one-liners, to make "sub" and "update" return CoreInfo.exnOrd, instead of CoreInfo.exnSubscript in inlstore and inlbyteof. I enclose the patch at the end. *** inlineops.sml.~1~ Wed Nov 18 00:06:10 1992 --- inlineops.sml Sat Dec 26 18:18:20 1992 *************** *** 123,129 **** COND(APP(PRIM(P.LESSU,predTy), RECORD[vi,APP(PRIM(P.LENGTH,lengthTy),vs)]), APP(PRIM(P.ORDOF,ordofty),RECORD[vs,vi]), ! RAISE(conToLexp(!CoreInfo.exnSubscript),INTty))))) end (* Bytearray store: --- 123,129 ---- COND(APP(PRIM(P.LESSU,predTy), RECORD[vi,APP(PRIM(P.LENGTH,lengthTy),vs)]), APP(PRIM(P.ORDOF,ordofty),RECORD[vs,vi]), ! RAISE(conToLexp(!CoreInfo.exnOrd),INTty))))) end (* Bytearray store: *************** *** 154,160 **** COND(APP(PRIM(P.LESSU,predTy),RECORD[vc,INT 256]), APP(PRIM(P.STORE,storety),RECORD[vs,vi,vc]), RAISE(conToLexp(!CoreInfo.exnRange),INTty)), ! RAISE(conToLexp(!CoreInfo.exnSubscript),INTty)))))) end (* String ordof: --- 154,160 ---- COND(APP(PRIM(P.LESSU,predTy),RECORD[vc,INT 256]), APP(PRIM(P.STORE,storety),RECORD[vs,vi,vc]), RAISE(conToLexp(!CoreInfo.exnRange),INTty)), ! RAISE(conToLexp(!CoreInfo.exnOrd),INTty)))))) end (* String ordof: Status: fixed in 0.93c (dbm) ---------------------------------------------------------------------- Number: 698 Title: Uninformative nonexhaustive match warning messages. Keywords: error messages, matches Submitter: John Reppy Date: 12/29/92 Version: 0.92 System: Sparcstation Severity: major Problem: Uninformative nonexhaustive match warning messages. Transcript: When compiling Isabelle/Pure: lexicon.ML:63.9-63.73 Warning: match nonexhaustive => ... lexicon.ML:55.9-61.62 Warning: match nonexhaustive => ... => ... => ... Comments: Looks like printdepth is set to low, but doesn't happen at top level. [appel: Isabelle actively resets the print depth, and brings this problem upon itself.] Status: not a bug ---------------------------------------------------------------------- Number: 699 Title: "Compiler bug: ModuleUtil: lookFormalBinding 1" (secondary) Keywords: modules, error recovery Submitter: John Reppy Date: 12/31/92 Version: 0.93b Severity: minor Problem: "Compiler bug: ModuleUtil: lookFormalBinding 1" generated as secondary error message after an unbound signature reference. Code: (contents of file trace-cml.sml) functor TraceCML ( structure CML : INTERNAL_CML and RunCML : RUN_CML and CIO : CIO (* <== should have been signature CONCUR_IO *) sharing CML = RunCML.CML = CIO.CML ) : TRACE_CML = struct structure CIO = CIO (* where to direct trace output to *) datatype trace_to = TraceToOut | TraceToErr | TraceToNull | TraceToFile of string | TraceToStream of CIO.outstream end; (* TraceCML *) Code: (simplified) functor F(structure A : sig end structure B : SXX (* undefined sig SXX *) sharing A = B.C) = (* undefined component B.C -- error msg *) struct end Transcript: [opening trace-cml.sml] trace-cml.sml:13.14-13.16 Error: unbound signature: CIO Error: Compiler bug: ModuleUtil: lookFormalBinding 1 [closing trace-cml.sml] Fix: added a case: | STRbind(STRvar{binding=STR_FORMAL{spec=ERROR_SIG,...},...}) => raise ErrorStructure in function lookFormalBinding in modules/moduleutil.sml. Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 700 Title: wrong printing with toplevel vector pattern Keywords: printing, top level Submitter: Dave MacQueen Date: 1/3/93 Version: 0.93b Severity: minor Problem: Top level does not print value bindings when a vector pattern is used. Transcript: Standard ML of New Jersey, Version 0.93b, December 14, 1992 val it = () : unit - val #[x,y,z] = #[1,2,3,]; std_in:2.1-2.23 Warning: binding not exhaustive #[x,y,z] = ... - - val [x,y] = [3,4]; std_in:0.0-0.0 Warning: binding not exhaustive x :: y :: nil = ... val x = 3 : int val y = 4 : int - Comment: Note also the extra newlines for the printing of the list bindings. Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 701 Title: wrong types printed for top-level exception declarations Keywords: printing, types, exceptions, top level Submitter: Andrzej Filinski Date: 1/12/93 Version: 0.92 (November 18, 1992) System: all Severity: minor Problem: wrong types printed for top-level exception declarations Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - exception E; exception E [ok] - exception E of int; exception E [same for all non-functional types] - exception E of int->bool; exception E of int [only codomain reported for functional types] Fix: changed print/ppdec.sml Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 702 Title: realfloor is unimplemented Keywords: floats, realfloor Submitter: Thomas Yan, tyan@cs.cornell.edu Date: 1/12/93 Version: .75, .92 (so presumably ever since .75) Severity: major Problem: realfloor is unimplemented Comments: hard to work around -- need to know/compute internal representation of floats Suggestion: [appel] local val maxint = 4503599627370496.0 (* This is the IEEE double-precision maxint; won't work accurately on VAX *) fun realround x = if x>=0.0 then x+maxint-maxint else x-maxint+maxint (* realround(x) returns x rounded to some nearby integer, almost always the nearest integer. *) in fun realfloor x = let val y = realround x in if y>x then y-1.0 else y end end Owner: Status: obsolete ---------------------------------------------------------------------- Number: 703 Title: betaexpand in cpsopt goes into infinite loop Keywords: code generation, infinite loop Submitter: Greg Morrisett Date: 1/13/93 Version: 0.92 System: Mips Mach, Sparc Mach, (probably all) Severity: critical Problem: betaexpand in cpsopt goes into infinite loop Code: val rec f = fn true => f false | false => f true Transcript: Standard ML of New Jersey, Version 0.92, November 18, 1992 val it = () : unit - val rec f = fn true => f false | false => f true; [Major collection... [Increasing heap to 2741k] [Increasing heap to 2941k] [Increasing heap to 3941k] [Increasing heap to 7001k] 95% used (2120604/2211028), 2078 msec] Comments: Don't be fooled by the fact that this code doesn't terminate. The original code that I whittled down to this *did* terminate. It was a slight modification of cps/contract.sml. Let me know if you want the original code... Comment: [Greg, 1/18/93] I'm not so sure that the problem is just in betaexpand, now. The example code I gave you compiles if you turn betaexpand off, but my real code only compiles if you turn off all of cpsopt. Comment: (awa) Compilation of his original (large) program did not infinite loop! It merely kept going for approximately 14^6 beta-expansions, which took a long time and a lot of space. [understatement] Fix: [temporary. awa, 1/19/93] System.Control.CG.unroll := false; [permanent, awa, 1/20/93] Add "andalso n < max" to UNROLL case in body of function should_expand in cps/expand.sml. Also, let max=2, not max=5 (which was excessive) Status: fixed in 0.93c (awa) ---------------------------------------------------------------------- Number: 704 Title: System.Unsafe.SysIO.access raises exception instead of returning false Keywords: Submitter: John Reppy (jhr@research.att.com) Date: 1/14/93 Version: 0.93 (and earlier) System: all Severity: minor Problem: System.Unsafe.SysIO.access raises an exception when its argument is inaccessable, instead of returning false. Code: System.Unsafe.SysIO.access ("some-file-that-does-not-exist", []); Transcript: Standard ML of New Jersey, Version 0.93a, December 9, 1992 val it = () : unit - System.Unsafe.SysIO.access ("some-file-that-does-not-exist", []); uncaught exception SystemCall Comments: In the long run, there should be a datatype for the return value of access, since it can fail for significantly different reasons (e.g., no such file, not a directory, looping path, ...). Fix: Change the code in cfuns.c to return false instead of raising SystemError Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 705 Title: sml emacs subprocess dies when file is "used" Keywords: emacs Submitter: David Ladd (ladd@research.att.com) Date: 1/21/92 Version: 0.93a System: SGI, R3000, IRIX 4.0.4 Severity: major Problem: The following file works fine if ``used'' from the shell prompt, but dies when ``used'' under emacs. Code: (file bug705.sml) exception foo; fun foo'(x) = raise foo; foo'(4); Transcript: Standard ML of New Jersey, Version 0.93a, December 9, 1992 val it = () : unit - [opening /tmp/t] exception foo val foo' = fn : 'a -> 'b [closing /tmp/t] uncaught exception foo uncaught exception (Loader): SystemCall Process cmusml finished Owner: Status: not reproducible ---------------------------------------------------------------------- Number: 706 Title: non-terminating structure compilation Keywords: modules, signatures, signature matching, infinite loop Submitter: Knut Omang (Univ. of Oslo), knuto@ifi.uio.no Date: 1/8/93 Version: 0.75 System: ds & sun4 (the below run done on a Sun Sparcstation 2) Severity: major Problem: non-terminating structure compilation Code: -------- structure Queue1 = struct type 'a T = 'a list; exception E; fun hd(x::q) = x | hd [] = raise E; end signature QUEUE = sig type 'a T exception E val hd : 'a T -> 'b T end; structure Q1: QUEUE = Queue1; Transcript: ------------ Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - use "qm.sml"; [opening qm.sml] structure Queue1 : sig eqtype 'a T exception E val hd : 'a list -> 'a end signature QUEUE = sig type 'a T exception E val hd : 'a T -> 'b T end [Major collection... [Increasing heap to 2116k] [Increasing heap to 2636k] [Increasing heap to 5236k] 97% used (1614112/1649172), 1240 msec] [Increasing heap to 8012k] [Major collection... [Increasing heap to 11916k] 95% used (4137248/4349188), 3120 msec] [Increasing heap to 12752k] ^C[closing qm.sml] Interrupt - Comments: This program should probably terminate quickly with an error msg.. Status: fixed in 0.75 ---------------------------------------------------------------------- Number: 707 Title: overloading in the profiler Keywords: profiler, overloading Submitter: Lal George Date: 1/21/93 Version: 0.93b Severity: major Problem: Operators do not have their normal overloaded properties in the profiler. Transcript: - kisubi:$ smlp Standard ML of New Jersey, Version 0.93b, December 14, 1992[PROFILING] val it = () : unit - fun f x = x + 1; std_in:8.11-8.15 Error: operator and operand don't agree (tycon mismatch) operator domain: real * real operand: real * int in expression: + (x,1) Status: fixed in 0.93c (lal) ---------------------------------------------------------------------- Number: 708 Title: array too large Keywords: array, bounds Submitter: Carl Gunter Date: 1/25/93 Version: 0.93b System: Sparcstation Severity: major Problem: Allocating very large array leads to strange behavior. Transcript: bolete% sml Standard ML of New Jersey, Version 0.93b, December 14, 1992 val it = () : unit - open Array; ... - val A = array(100, true); val A = [|true,true,true,true,true,true,true,true,true,true,true,true,...|] : bool array - sub(A,5); val it = true : bool But this is different: bolete% sml Standard ML of New Jersey, Version 0.93b, December 14, 1992 val it = () : unit - open Array; ... - val A = array(1073741823, true); val A = [||] : bool array - sub(A,5); val it = false : bool - sub(A, 13098); ... emacs window freezes ... Comment: the size is too large to fit in the 26 bits reserved in the descriptor; the assembly language was not checking this. Fix: Change the ML code in perv.sml to check for size before calling assembly language. Status: fixed in 0.93c ---------------------------------------------------------------------- Number: 709 Title: bad indentation Keywords: printing, prettyprint, top level Submitter: Dave MacQueen Date: 1/26/92 Version: 0.93c System: Mips Magnum, RISCos 4.52 Severity: minor Problem: System printout after opening a structure (System.Compile) has bad indentation. Transcript: Standard ML of New Jersey, Version 0.93b, December 14, 1992 val it = () : unit - open System.Compile; open Compile structure PP : sig type ppconsumer end structure IO : sig type instream type outstream end structure Ast : sig type dec end exception Compile = Compile val makeSource = fn : string * int * instream * bool * System.PrettyPrint.ppconsumer -> source val closeSource = fn : source -> unit val changeLvars = fn : staticUnit -> staticUnit val elaborate = fn : source * staticEnv -> staticUnit val parse = fn : source * staticEnv -> Ast.dec * staticEnv val compile = fn : source * staticEnv -> staticUnit * codeUnit val compileAst = fn : Ast.dec * staticEnv * source option -> compUnit val execute = fn : (staticUnit * codeUnit) * environment -> environment val eval_stream = fn : instream * environment -> environment val use = fn : string -> unit val use_stream = fn : instream -> unit - - Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 710 Title: 0.0/0.0 generates strange float exception (on a NeXT) Keywords: Submitter: Joel F. Klein, Joel.Klein@Rose-Hulman.EDU Date: 1/28/93 Version: 0.75 System: NeXTstation Severity: minor Problem: 0.0/0.0 generates strange float exception (on a NeXT) Code: 0.0/0.0 Transcript: mercutio 9:50pm > sml Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - 0.0/0.0; strange floating point error, 0xd0 mercutio 9:52pm > Comments: This is a known and "fixed" bug, but NeXTs don't know that. Comments: [Joel Klein, 1/20/93] I have additional information on bug report 710. I left out which operating system the NeXT was running. This appears to be important, because the "normal" NeXTs around here have a different response to the same input. Here's the summary: NeXT running NeXTstep 3.0: 0.0/0.0 generates "strange float error" NeXT running NeXTstep 2.0: 0.0/0.0 returns 0.0 Example transscript of latter: - 0.0/0.0; val it = 0.0 : real [Appel:] SML/NJ 0.92 gives strange floating point error 0xd on NeXT 3.0. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 711 Title: SystemCall exceptions Keywords: SystemCall Submitter: Benli Pierce Date: 9/30/92 Version: 0.90 System: sparc Severity: major Problem: I've encountered one strange behavior while playing around with SML 0.90 on a sparc. Calls to System.system sometimes raise SystemCall exceptions -- not in a fresh sml-sg image, but after a while, when a few things have been compiled. I thought it must be a problem with running out of virtual memory, but I was able to get the same behavior after killing off several big processes. Comments: (David Shepherd, des@inmos.co.uk, 4/6/93) Basically just some further info on open bug 711. This seems to be linked to the amount of swap space available. System calls work fine in sml on my machine but fail when used in hol90. However, running on another sparcstation with much more swap space then it works fine again. For hol work this is pretty serious as it is normal to do a system call to delete a theory file before running the code to rebuild in in proof scripts! Hope (a) this info is helpful, (b) this bug gets fixed soon! Fix: Get some more swap space :-( Owner: Status: obsolete ---------------------------------------------------------------------- Number: 712 Title: Compiler bug: Modules.distributeT:f DD146 Keywords: modules, functors, local spec Submitter: Tyng-Ruey Chuang, chuang@cs.nyu.edu Date: 10/27/92 Version: 0.75 System: Sun Sparc, O.S. version 4.1.1 Severity: not major Problem: Compiler-error when local specification is used with type sharing equation in a signature declaration. Code: Note: named as "bug.sml" in Transcript. (*----------------------------------------------------------------------------*) (* Signature "FLIP" and its associated functor "Flip" *) signature FLIP = sig datatype Side = LHS | RHS end functor Flip () : FLIP = struct datatype Side = LHS | RHS (* LHS for left-hand-side and RHS for right-hand-side *) end (*----------------------------------------------------------------------------*) (* Signature "FLOP" and its associated functor "Flop". Signature "FLOP" is identical(?) to "FLIP" though their names are different. Functor "Flop" should generate a structure identical to its input structure. *) signature FLOP = sig local structure flip : FLIP in datatype Side = LHS | RHS sharing type Side = flip.Side end end functor Flop (flip : FLIP) : FLOP = struct local structure flip = flip in open flip end end (*----------------------------------------------------------------------------*) (* A test to see if the following structures are identical(?). *) structure flip = Flip () structure flop = Flop (flip) val identical = flip.LHS = flop.LHS Transcript: Script started on Tue Oct 27 17:16:00 1992 spunky% sml Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - use "bug.sml"; [opening bug.sml] bug.sml:24.5-24.26 Warning: LOCAL specs are only partially implemented Error: Compiler bug: Modules.distributeT:f DD146 [closing bug.sml] - ^D spunky% ^D script done on Tue Oct 27 17:16:18 1992 Comments: The bug goes away if either local specifications in signatures are removed or sharing equation is removed. For example: (*----------------------------------------------------------------------------*) (* Signature "FLIP" and its associated functor "Flip" *) signature FLIP = sig datatype Side = LHS | RHS end functor Flip () : FLIP = struct datatype Side = LHS | RHS (* LHS for left-hand-side and RHS for right-hand-side *) end (*----------------------------------------------------------------------------*) (* Signature "FLOP" and its associated functor "Flop". Signature "FLOP" is identical(?) to "FLIP" though their names are different. Functor "Flop" should generate a structure identical to its input structure. *) signature FLOP = sig structure flip : FLIP (* NO local declaration here. *) datatype Side = LHS | RHS sharing type Side = flip.Side end functor Flop (flip : FLIP) : FLOP = struct structure flip = flip (* NO local declaration here. *) open flip end (*----------------------------------------------------------------------------*) (* A test to see if the following structures are identical(?). *) structure flip = Flip () structure flop = Flop (flip) val identical = flip.LHS = flop.LHS OR (*----------------------------------------------------------------------------*) (* Signature "FLIP" and its associated functor "Flip" *) signature FLIP = sig datatype Side = LHS | RHS end functor Flip () : FLIP = struct datatype Side = LHS | RHS (* LHS for left-hand-side and RHS for right-hand-side *) end (*----------------------------------------------------------------------------*) (* Signature "FLOP" and its associated functor "Flop". Signature "FLOP" is identical(?) to "FLIP" though their names are different. Functor "Flop" should generate a structure identical to its input structure. *) signature FLOP = sig datatype Side = LHS | RHS end functor Flop (flip : FLIP) : FLOP = struct open flip end (*----------------------------------------------------------------------------*) (* A test to see if the following structures are identical(?). *) structure flip = Flip () structure flop = Flop (flip) val identical = flip.LHS = flop.LHS Status: not a bug ---------------------------------------------------------------------- Number: 713 Title: sourcegroups crashes in a non-deterministic fashion. Keywords: Sourcegroup Submitter: Lal George Date: 10/28/92 Version: 0.91 System: RS6000 Severity: major Problem: sourcegroups crashes in a non-deterministic fashion. Code: Compile sourcegroups version 2.2. (This was brought to my attention by cliff@cs.cornell.edu) Transcript: [/usr/u/plg/SMLofNJ/91/tools/sourcegroup] bashful% sml-91 Standard ML of New Jersey, Version 0.91, October 26, 1992 val it = () : unit - use "build.sml"; [opening build.sml] val print'sigs = 2 : int val it = () : unit [opening load-all.sml] [opening local/System/interrupt.sig] signature INTERRUPT = ... [closing local/System/interrupt.sig] val it = () : unit [opening local/System/interrupt.sml] structure Interrupt : INTERRUPT [closing local/System/interrupt.sml] val it = () : unit [opening local/System/ioStream.sig] signature IO_STREAM = ... [closing local/System/ioStream.sig] val it = () : unit [opening local/System/ioStream.sml] structure IO_Stream : IO_STREAM [closing local/System/ioStream.sml] val it = () : unit [opening tools/sepcomp.sml] [Major collection... [Increasing heap to 2719k] [Increasing heap to 2979k] 33% used (729592/2187412), 200 msec] [Increasing heap to 3643k] signature SEPCOMP = ... structure SepComp : SEPCOMP [closing tools/sepcomp.sml] val it = () : unit [opening tools/compile.sml] signature COMPILE = ... structure Compile : COMPILE [closing tools/compile.sml] val it = () : unit val it = () : unit val load = fn : string -> unit [reading base.sml] [Major collection... [Increasing heap to 3711k] [Increasing heap to 4051k] 32% used (955024/2984028), 310 msec] [Increasing heap to 4743k] [Major collection... 17% used (697240/3897980), 230 msec] [closing base.sml] val it = () : unit [reading local/System/pathname.sig] [closing local/System/pathname.sig] val it = () : unit [reading local/System/ioStream.sig] [closing local/System/ioStream.sig] Illegal instruction ====================================================================== Fix: The bug is caused by the lack of cache flushing after code generation. Add the line System.Unsafe.CInterface.flush_cache wherever appropriate. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 714 Title: failure of ByteArray.update Keywords: ByteArray Submitter: Fred Sullivan (sullivan@cs.rose-hulman.edu) Date: 11/2/92 Version: 0.75 System: NeXT and Sun 3/SunOS Severity: major Problem: ByteArry.update seems to fail in the following circumstances: 1. System.Control.interp is false. 2. update is called at top level. Transcript: Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - open ByteArray; open ByteArray - val a = array(5, 65); val a = - : bytearray - extract (a, 0, 5); val it = "AAAAA" : string - update (a, 3, 66); val it = () : unit - extract (a, 0, 5); val it = "AAAAA" : string - update (a, 0, 67); val it = () : unit - extract (a, 0, 5); val it = "\000AAAA" : string - If update is not called at top level, it seems to work: - fun foo (a, m, n) = update (a, m, n); val foo = fn : bytearray * int * int -> unit - foo(a, 0, 67); val it = () : unit - extract (a, 0, 5); val it = "CAAAA" : string - Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 715 Title: chdir often doesn't work on strings of length 0 mod 4 Keywords: System, directory Submitter: Andrew Tolmach (apt@cs.pdx.edu) Date: 11/6/92 Version: 0.90 (and perhaps earlier versions) System: all Severity: minor Problem: chdir often doesn't work on strings of length 0 mod 4 Code: System.Unsafe.CInterface.chdir "abcd"; (* this directory does exist *) Transcript: % sml Standard ML of New Jersey, Version 0.90 September 22, 1992 val it = () : unit - System.Unsafe.CInterface.chdir "abcd"; (* this directory does exist *) uncaught exception SysError - Comments: Caused by failure to call c_string on argument to chdir in boot/perv.sml. String seen by C may have arbitrary garbage after it. Fix: Replace val chdir : string -> unit = c_function "chdir" by val chdir : string -> unit = c_function "chdir" o c_string in boot/perv.sml. Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 716 Title: overflow on real operation crashes sml on sparc Keywords: float, overflow, sparc Submitter: Masahiro YASUGI < yasugi@is.s.u-tokyo.ac.jp > Date: 11/27/92 Version: Standard ML of New Jersey, Version 75, November 11, 1991 System: Sun4/SunOS Release 4.1.1-JLE1.1.1RevB Severity: rare Problem: An overflow on real number in sequential execution causes a crash of sml. Code: fun bug r = ( r * r; r:real ); bug 1.0E160; or fun bug r = ( r /0.0; r ); bug 1.0; Transcript: % sml Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - fun bug r = ( r /0.0 ; r :real ); val bug = fn : real -> real - bug 1.0; Segmentation fault % Comments: It seems to be a lower-level problem. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 717 Title: records always evaluated in alphabetical order Keywords: records, evaluation Submitter: Thomas Yan, tyan@cs.cornell.edu Date: 12/10/92 Version: 0.92 Severity: major Problem: records always evaluated in alphabetical order Code: val _ = {b= print "1", a = print "2"} Transcript: - val _ = {b= print "1", a = print "2"}; 21 - Comments: aren't records supposed to be evaluated in the order they appear in program text? Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 718 Title: accepts type incorrect program, crashes Keywords: types, type checking, crash Submitter: Norman Neff neff@trenton.edu Date: 1/26/93 Version: 0.75 System: Sun SPARC 1+ Sun OS 4.1.1 Severity: critical Problem: compiler accepts type-incorrect program, execution nonterminates Code: (* binary arithmetic *) val max'digits=100; structure Bins (*: sig exception add'oflow exception doub'oflow exception expadd'oflow exception btr'oflow exception btd'oflow val add'2 : ByteArray.bytearray * ByteArray.bytearray -> ByteArray.bytearray val subtract'2 : ByteArray.bytearray * ByteArray.bytearray -> ByteArray.bytearray val binary'to'int : ByteArray.bytearray -> int val is'zero : ByteArray.bytearray -> bool val binary'to'real : ByteArray.bytearray -> real val int'to'binary : int -> ByteArray.bytearray val real'to'binary : real -> ByteArray.bytearray val expadd : int * ByteArray.bytearray -> ByteArray.bytearray val double : ByteArray.bytearray -> ByteArray.bytearray val less'2 : ByteArray.bytearray * ByteArray.bytearray -> bool val lesseq'2 : ByteArray.bytearray * ByteArray.bytearray -> bool val print'2 : ByteArray.bytearray -> unit val zero : unit -> ByteArray.bytearray infix add'2 subtract'2 less'2 lesseq'2 end *)= let open ByteArray; in struct exception expadd'oflow exception add'oflow exception doub'oflow exception rtb'oflow infix add'2 less'2 lesseq'2 subtract'2 quot'rem div'2 fun print'2 n=revapp print n fun zero {}= array(max'digits,0); fun expadd(exponent,number)= (* destructively add 2**exponent to number *) let fun up({},pos,carry)= if carry=0 then {} else if pos >= max'digits then raise expadd'oflow else if (number sub pos)=0 then up(update(number,pos,1),pos+1,0) else up(update(number,pos,0),pos+1,1) val dummy= up({},exponent,1) in number end; fun add(n1,n2,carry'expect)= let val ans=zero{}; fun col({},i,carry)=if (i < max'digits) then case ((n1 sub i)+(n2 sub i)+carry) of 0 => col({},i + 1, 0) | 1 => col(update(ans,i,1),i + 1, 0) | 2 => col(update(ans,i,0),i + 1, 1) | 3 => col(update(ans,i,1),i + 1, 1) else if carry=carry'expect then ans else raise add'oflow in col({},0,0) end fun n1 add'2 n2 = add(n1,n2,0) fun succ n=let val ans=n add'2 (zero{}); in expadd(0,ans) end val ONE=succ (zero{}); fun double n= let val ans=zero{}; fun col({},i)= if ((i >= max'digits) andalso (n sub (i-1))=1) then raise doub'oflow else if (i < max'digits) then col(update(ans,i,n sub (i - 1)),i + 1) else ans in col({},1) end fun twos'complement n=let val one'comp=zero{} fun col({},i)=if (i < max'digits) then col(update(one'comp,i,1-(n sub i)),i+1) else one'comp in expadd(0,col({},0) ) end fun is'zero n=let fun f (a, b) =((a=0) andalso b) in fold f n true end fun n1 subtract'2 n2=if (is'zero n2) then (n1 add'2 zero{}) else add(n1,twos'complement n2,1) local fun cp(n1,n2,ms)=if ms<0 then true else if (n1 sub ms)<(n2 sub ms) then true else if (n1 sub ms)>(n2 sub ms) then false else cp(n1,n2,ms - 1) in fun op lesseq'2(n1,n2)=cp(n1,n2,max'digits-1) fun op less'2(n1,n2)=not (cp(n2,n1,max'digits-1)) end fun a quot'rem b=if (a less'2 b) then (zero{},a) else let val (q,r)= a quot'rem (double b) in if (r less'2 b) then (double q,r) else ((double q) add'2 ONE, r subtract'2 b) end fun a div'2 b=let val (q,r)=(a quot'rem b) in q end exception rtb'oflow fun int'to'binary 0 = zero{} | int'to'binary x = if ((x mod 2)=0) then double (int'to'binary (x div 2)) else succ (double (int'to'binary (x div 2))) fun real'to'binary 0.0=zero() | real'to'binary x= let val lx =(ln x)/(ln 2.0) val sigbits=30.0 (*supported by both int & float *) val shift=ceiling(lx-sigbits) fun sh2 0 binbase=binbase add'2 (zero{}) | sh2 n binbase=double(sh2 (n-1) binbase) fun exp2 lx= if (lx < sigbits) then int'to'binary(floor (exp (lx * (ln 2.0)) + 0.5) ) else (sh2 shift (exp2 (lx- shift))) (* BUG : should be (lx - (real shift)) *) in ( exp2 lx) handle doub'oflow => raise rtb'oflow end val TWO=succ ONE exception btd'oflow fun binary'to'int n= if is'zero(n) then 0 else if is'zero(n subtract'2 ONE) then 1 else let val (q,r)=n quot'rem TWO in (if is'zero(r) then 2*(binary'to'int q) else 1 + 2*(binary'to'int q)) handle Overflow =>raise btd'oflow end exception btr'oflow fun binary'to'real n= if is'zero(n) then 0.0 else if is'zero(n subtract'2 ONE) then 1.0 else let val (q,r)=n quot'rem TWO in (if is'zero(r) then 2.0*(binary'to'real q) else 1.0 + 2.0*(binary'to'real q)) handle Overflow =>raise btr'oflow end end end open Bins; val d=real'to'binary 1E12; Transcript: NOTE: Emacs, Inferior Smld Standard ML of New Jersey, Version 75, November 11, 1991 Arrays have changed; see Release Notes val it = () : unit - emacsInit (); cd "/home/snuffy/faculty/neff/geom/"; val it = () : unit val it = () : unit - use "bug.sml"; [opening bug.sml] val max'digits = 100 : int bug.sml:53.6-57.43 Warning: match not exhaustive 0 => ... 1 => ... 2 => ... 3 => ... structure Bins : sig exception add'oflow exception btd'oflow exception btr'oflow exception doub'oflow exception expadd'oflow exception rtb'oflow val ONE : ?.Dummy.A.bytearray val TWO : ?.Dummy.A.bytearray val add : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray * int -> ?.Dummy.A.bytearray val add'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val binary'to'int : ?.Dummy.A.bytearray -> int val binary'to'real : ?.Dummy.A.bytearray -> real val div'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val double : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val expadd : int * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val int'to'binary : int -> ?.Dummy.A.bytearray val is'zero : ?.Dummy.A.bytearray -> bool val less'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> bool val lesseq'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> bool val print'2 : ?.Dummy.A.bytearray -> unit val quot'rem : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray * ?.Dummy.A.bytearray val real'to'binary : real -> ?.Dummy.A.bytearray val subtract'2 : ?.Dummy.A.bytearray * ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val succ : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val twos'complement : ?.Dummy.A.bytearray -> ?.Dummy.A.bytearray val zero : unit -> ?.Dummy.A.bytearray infix add'2 infix div'2 infix less'2 infix lesseq'2 infix quot'rem infix subtract'2 end open Bins NOTE: After several minutes of non-response, interrupt produced: Process Inferior smld bus error Comments: I suspect that part of the problem is ceiling, which shows type real->'a rather than what is in the specs Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 719 Title: weakness zero polymorphism allowed in structures Keywords: types, weak types, polymorphism Submitter: Andrew Wright (wright@cs.rice.edu) Date: 1/26/93 Version: 0.93 Severity: Critical (type checking error) Problem: In playing around with version 92, I noticed that the following code type checks, assigning f the type '0Z -> '0Z. This code is rejected by version 75. Code: structure Foo = struct val f = ! (ref (fn x => x)) end Comments: Is this a bug? Or are you intending to extend SML to allow this structure to match the signature: signature FOO = sig val f : int -> int end [dbm] It's a bug. Fix: change line 1014 of elaborate/elabstr.sml, replacing "isTop kind" with "true". Status: fixed in 0.93 ---------------------------------------------------------------------- Number: 720 Title: when opening a structure at top-level, types are not printed Keywords: open, top level, printing Submitter: John Reppy (jhr@research.att.com) Date: 1/29/93 Version: 0.92 (and pre-release 0.93) System: any Severity: minor Problem: when opening a structure at top-level, types are not printed Transcript: Standard ML of New Jersey, Version 0.93, February 1, 1993 val it = () : unit - structure Foo = struct datatype t = T of int val x = T 0 end; structure Foo : sig datatype t con T : int -> t val x : t end - open Foo; open Foo val x = T 0 : t - Comments: [dbm] Currently only the dynamic elements of a structure are printed when the structure is opened at top level. This is a side effect of the fact that all dynamic components are being rebound in the toplevel environment. This is the same as bug 666. Fix: perform special printing for open, suppressing the printing due to the rebinding of dynamic components. Owner: dbm Status: fixed in 109.31 [dbm, 7/15/97] ---------------------------------------------------------------------- Number: 721 Title: Local weakness 0 typing rejected. Keywords: types, weak types Submitter: Mark Lillibridge (mdl@cs.cmu.edu) Date: 2/1/93 Version: 0.93 Severity: critical Problem: Local weakness 0 typing rejected. Code: local val f = !(ref(fn x =>x)) in val y = 3 end; Transcript: - local val f = !(ref(fn x =>x)) in val y = 3 end; std_in:2.7-2.30 Error: nongeneric weak type variable f : '0Z -> '0Z Comments: On the other hand, the following code should be rejected, because context across structure boundaries is not allowed. local structure Foo = struct val f = !(ref(fn x=> x)) end in val y = 3 end; See also bug 719. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 722 Title: core dump (illegal instruction) on Sun 3, NeXT loading smlnj-lib Keywords: illegal instruction, crash Submitter: Tom Kirk, Dave MacQueen Date: 2/6/93 Version: 0.93 System: NeXT 3.0, Sun 3/SunOS 4.1.1 Severity: critical Problem: Core dumps while loading the smlnj library. Transcript: (in the smlnj-lib directory) iota$ sml Standard ML of New Jersey, Version 0.93, February 1, 1993 val it = () : unit - use "load-all"; ... [Increasing heap to 6702k] structure Format : FORMAT [opening string-util-sig.sml] signature STRING_UTIL = sig exception NotFound val index : string -> string * int -> int ... end [opening string-util.sml] [Major collection... 18% used (1014324/5486980), 3920 msec] Illegal instruction iota$ Comments: Bug is repeatable. Happens just after opening string-util.sml every time. Status: fixed in 0.93 (Lal George) ---------------------------------------------------------------------- Number: 723 Title: obsolete components of System.Print and System.Control Keywords: obsolete components Submitter: Dave MacQueen Date: 2/6/93 Version: 0.93 Severity: Minor Problem: The obsolete component System.Print.pathnames has not been deleted. Comments: System.Control.Print is also redundant now. Fix: delete these components from system.sig and perv.sml. Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 724 Title: minor prettyprinting bug Keywords: printing, prettyprint Submitter: John Reppy Date: 2/7/93 Version: 0.93 Severity: minor Problem: Consider the following output from the pretty printer: structure PolyHashTable : sig datatype ('a,'b) bucket_t con B : int * 'a * 'b * ('a,'b)bucket_t -> ('a,'b)bucket_t con NIL : ('a,'b)bucket_t ... The "('a,'b)" has a space following it in the datatype line, but not in type expressions. Status: fixed in 0.93 (dbm) ---------------------------------------------------------------------- Number: 725 Title: fragility of quote/antiquote implementation Keywords: Submitter: Andrew Appel Date: 2/2/93 Version: 0.93 Severity: major Problem: One can redefine the QUOTE constructor, and this imposter will then be used in the expansion of quotations. Code: Transcript: Standard ML of New Jersey, Version 0.93, February 1, 1993 val it = () : unit - System.Control.quotation:=true; val it = () : unit - datatype 'a frag = QUOTE of string | ANTIQUOTE of 'a | NOTHING; datatype 'a frag con ANTIQUOTE : 'a -> 'a frag con NOTHING : 'a frag con QUOTE : string -> 'a frag - - val j = `hello`; val j = [QUOTE "hello"] : 'a frag list - fun f NOTHING = "none" | f (QUOTE s) = s; std_in:6.1-6.40 Warning: match nonexhaustive NOTHING => ... QUOTE s => ... val f = fn : 'a frag -> string - map f j = ; val it = ["hello"] : string list Fix: make sure the expansion uses the 'real' QUOTE constructor. Don't just pick it up from the current top-level environment. Owner: Status: open ---------------------------------------------------------------------- Number: 726 Title: non-polymorphic function in scope of recursive def (not a bug) Keywords: type checking Submitter: Tim Sheard (sheard@cse.ogi.edu, 503-690-1439) Date: 2/11/93 Version: 0.93 Severity: major Problem: There seems to be a bug in the type checker for sml version 0.93 run on a sparc station. Consider the two declarations below, When I attempt to compile them the second one causes a type error. Code: input file "/projects/pacsoft/tools/crml/bugs/smlreport" datatype 'a test = C1test of (string * 'a test) list | C2test of (('a test) list) * 'a; val map_test = let fun map_list a_f [] = [] | map_list a_f (x1::x2) = (a_f x1)::(map_list a_f x2) and map_test a_f (C1test x1) = C1test (map_list (fn (y1,y2) => (y1,map_test a_f y2)) x1) | map_test a_f (C2test (x1,x2)) = C2test (map_list (map_test a_f) x1,a_f x2) in map_test end; Transcript: Standard ML of New Jersey, Version 0.93, February 1, 1993 val it = () : unit - - use "/projects/pacsoft/tools/crml/bugs/smlreport"; [opening /projects/pacsoft/tools/crml/bugs/smlreport] datatype 'a test con C1test : (string * 'a test) list -> 'a test con C2test : 'a test list * 'a -> 'a test /projects/pacsoft/tools/crml/bugs/smlreport:13.49-13.83 Error: operator and operand don't agree (tycon mismatch) operator domain: string * 'Z test -> string * 'Y test operand: 'Z test -> 'Y test in expression: map_list (map_test a_f) [closing /projects/pacsoft/tools/crml/bugs/smlreport] - yet if I type the following, without mutual recursion: - val map_test = = let fun map_list a_f [] = [] = | map_list a_f (x1::x2) = (a_f x1)::(map_list a_f x2) = fun map_test a_f (C1test x1) = C1test (map_list (fn (y1,y2) => (y1,map_test a_f y2)) x1) = | map_test a_f (C2test (x1,x2)) = C2test (map_list (map_test a_f) x1,a_f x2) = in map_test end; val map_test = fn : ('a -> 'b) -> 'a test -> 'b test - it compiles ok. In this example I don't need mutual recursion but for more complicated ones I do. I tried to reproduce the error with the smallest example I could find. Comments: [dbm] SML doesn't allow you to use a function polymorphically in its own (mutually) recursive definition. It would be possible to relax this restriction (Milner-Mycroft type system), but then typing is undecideable (Kfoury & Tiuryn). One could find a pragmatic way around this that would generally work fine (CAML (Light?) does), but it doesn't seem to be a critical need in practice, at least in our experience. Status: not a bug, but a fact of life ---------------------------------------------------------------------- Number: 727 Title: printing sharing constraints in signature Keywords: modules, signatures, sharing, printing Submitter: Dave MacQueen Date: 2/11/93 Version: 0.93 Severity: minor Problem: Code: (based on $sml/testing/modules/tests/test64.sml) functor F (X : sig end) = X; structure A = struct type t = int end; structure B = F (A); signature S = sig structure C : sig type t end sharing C = B end; Transcript: - use "bug727.sml"; [opening bug727.sml] functor F : structure A : sig eqtype t end structure B : sig end signature S = sig structure C : ... sharing C = ?.B. (* bogus printout of B *) end val it = () : unit - Comments: The problem is that the internal path of structure B is reversed: ".B" instead of "B.". Owner: Status: obsolete ---------------------------------------------------------------------- Number: 728 Title: opening a structure with substructure of same name at top level Keywords: modules, open, top level, scoping Submitter: Dave MacQueen, John Reppy Date: 2/15/93 Version: 0.93 Severity: minor? Problem: Opening a structure at top level when the structure has a substructure of the same name may cause an error Code: structure A : sig structure A : sig end structure B : sig end end = struct structure A = struct end structure B = struct end end; open A; (* at top level *) Transcript: Standard ML of New Jersey, Version 0.93, February 12, 1993 val it = () : unit - use "bug728.sml"; [opening bug728.sml] structure A : sig structure A : ... structure B : ... end bug728.sml:11.1-11.6 Error: unbound structure: B in path A.B - Fix: In elaborate/elabstr.sml, locally rebind the new structure to a special name and use this special name as the intermediary in rebinding the components. E.g. in the above example, the redeclarations produced by "open A" take the form local structure %str% = A in structure A = %str%.A structure B = %str%.B end instead of the erroneous structure A = A.A structure B = A.B (* no A.B found *) Status: fixed in 0.93 (except didn't make into Mac version *) ---------------------------------------------------------------------- Number: 729 Title: include causes type sharing violation Keywords: modules, signatures, include, sharing Submitter: Alexander Horz (GMD; horz@gmd.de) Date: 8/3/93 System(s) and Version: smlsg, noshare SML/NJ Version: 0.93 Machine: sparc, sunos Severity: **** critical **** Problem: *serious* problem with "include" in functor declarations: after successfully compiling signature TERM = sig ... end and functor Term (...) : TERM = struct ... end there is no problem in compiling structure Terms2 : TERM = Term( ... ) However, when replcaing the second piece of code by functor Term(...) :sig include TERM val comp ... end = struct ... end the compiler produces a mysterios error message (see, below) instead of successfully compiling structure Terms2 : TERM = Term( ... ) I cut the original code down to a sufficiently small length. The error producing code is split into three files: file "TERM.sml" contains all the signatures, file "Term.sml" the Term functor, and file example contains the code for the example application of Term that produces the error message, presented at the end. Code: (bug729.sml: a short version. bug729a.sml contains original version) signature ELEMENT = sig type t val put : unit (* necessary *) end; signature TERM = sig structure S : sig include ELEMENT end type subst sharing type subst = S.t end; functor Term () : sig include TERM end = (* ": TERM" works ok *) struct structure S = struct datatype t = C (* must be datatype -- "type t = unit" works ok *) val put = () end type subst = S.t end; structure Terms : TERM = Term(); (* signature ": TERM" necessary *) Transcript: (in 103d) - use "bug729.sml"; [opening b.sml] signature ELEMENT = sig type t val put : unit end signature TERM = sig structure S : ... type subst sharing type S.t = subst end functor Term : b.sml:30.11-30.31 Error: type sharing violation S.t # subst - Status: fixed in 105 ---------------------------------------------------------------------- Number: 730 Title: reappearance of bug 705 on RS/6000 Keywords: rs6000, emacs Submitter: Cliff Krumvieda (cliff@cs.cornell.edu) Date: 2/19/93 System and Version: Compiler SML/NJ Version: 0.93 Machine: IBM RS/6000, AIX 3.2 Severity: Major (IMHO) Problem: Bug number 705: sml emacs subprocess dies when file is "used" (on some SGI machines) seems to have migrated to the IBM RS/6000. It wasn't present in 0.92. Transcript: ====================================================================== Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "bleg"; Quit (no coredump) Process Inferior cml finished ====================================================================== Owner: Status: open ---------------------------------------------------------------------- Number: 731 Title: exportML seems to be incorrectly searching paths Keywords: exportML, paths Submitter: Cliff Krumvieda (cliff@cs.cornell.edu) Date: 2/19/93 System and Version: Compiler SML/NJ Version: 0.93 Machine: IBM RS/6000, AIX 3.2 Severity: Minor Problem: exportML seems to be incorrectly searching paths. I have no idea why it is doing so or even why it is searching paths in the first place. Transcript(s): ====================================================================== [~plg/bin/rs6000] bashful% which ml-93 ./ml-93 [~plg/bin/rs6000] bashful% ml-93 Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - exportML "/usr/u/cliff/temp2/temp"; [Major collection... 99% used (558432/563108), 200 msec] [Major collection... 99% used (560200/560368), 170 msec] chaseLinks: Could not find executable in path! export: getaoutname failed uncaught exception Io "exportML "/usr/u/cliff/temp2/temp": No such file or directory" - ====================================================================== [~plg/bin/rs6000] bashful% which sml-93 /home/plg/bin/sml-93 [~plg/bin/rs6000] bashful% sml-93 Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - exportML "/usr/u/cliff/temp2/temp"; [Major collection... 99% used (558432/563096), 190 msec] [Major collection... 99% used (560188/560356), 160 msec] val it = false : bool - ====================================================================== Comments: /home/plg/bin/sml-93 is a link to ~plg/bin/rs6000/sml-93. Note that both sml-93 and ml-93 are on my search path, but ml-93 is only in ./ml-93. This problem doesn't exist on our Suns, but it did exist in 0.92 (I just hadn't noticed it before). Owner: John Status: fixed in 109.21 [new runtime] ---------------------------------------------------------------------- Number: 732 Title: Info.search does nothing but raise an exception Keywords: Info, environment Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/19/93 Version: 0.93 Problem: Info.search does nothing but raise an exception Code: Info.search "info" Transcript: - Info.search "info"; unbound uncaught exception Info the problem involves sourcegroup. Info works fine if loaded by itself; if loaded after sourcegroup, then there is a problem: agnar% sml Standard ML of New Jersey, Version 0.93, February 15, 1993 SML/NJ Library, Version 0.1, February 1, 1993 SourceGroup 3.0 val it = () : unit - Info.search ""; signature ABSYN signature ANALYZE (* etc. *) functor AbSynFun functor AnalyzeFun (* etc. *) structure AbSyn structure AbSyn. unbound uncaught exception Info - Also, from Eric Madelaine : Transcript: (in sml-sg) - Info.info["INFO"]; signature INFO = sig exception Info val info : string list -> unit val search : string -> unit end - Info.search"make"; unbound uncaught exception Info - Fix: (from Thomas Yan) here is a workaround (?fix): go on in spite of the "error". in the definition for search, add the line marked by (* *) if typ = "structure" then let val (subEnv,_) = strToEnv' [nom] env in search (nom::path,subEnv) (catalogEnv (staticPart subEnv)) end (* *) handle Info => print "going on in spite of error...\n" else (); Owner: Dave Status: obsolete [Info has to be reimplemented] ---------------------------------------------------------------------- Number: 733 Title: ml crashes -- (?) interaction between gc and system calls Keywords: crash Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 2/22/93 Version: 0.93 System: hppa Severity: major Problem: ml crashes -- (?) interaction between gc and system calls Code: see /dist/ml/incoming/tyan-bug.tar Transcript: handel% sml < load.sml Standard ML of New Jersey, Version 0.93, February 15, 1993 SML/NJ Library, Version 0.1, February 1, 1993 Concurrent ML -- version 0.9.8 -- February 1, 1993 SourceGroup 3.0 val it = () : unit - [opening timeit.sml] structure Timing (* etc. *) [opening test.sml] (* etc. *) val it = () : unit = [Major collection... 89% used (7571036/8482908), 2150 msec] [Increasing heap to 22186k] [Major collection... 99% used (7629928/7647148), 2283 msec] [Increasing heap to 22370k] Segmentation fault (core dumped) Comments: while trying to isolate the problem, i noticed it appeared sporadically, and was most likely to occur when starting with a small heap, e.g. using an executable from exportFn, and not, say, after a compilation/run that had already expanded the heap. to run the example, just use "load.sml". Owner: Status: obsolete ---------------------------------------------------------------------- Number: 734 Title: bug in profiler Keywords: profiler Submitter: Lal George Date: 3/3/93 System(s) and Version: tools/prof SML/NJ Version: 0.93 Severity: major Problem: I compiled a lot of code under the profiler and found that working programs were going into an infinite loop. Specifically, Intmap.rmv would increase the number of elements in the hash-table! Comment: The profile_script contains the following: structure Ref = struct open Ref fun inc i = i := !i + 1 fun dec i = i := !i + 1 end Status: fixed in 0.94 (later versions of) 0.93 ---------------------------------------------------------------------- Number: 735 Title: bad type error message Keywords: types, type checking, error messages Submitter: Anne Rogers (amr@princeton.edu) Date: 3/5/93 System(s) and Version: Compiler (0.93) SML/NJ Version: 0.93 Machine: any Severity: minor Problem: poor type error message Code: abstype 'a set = SET of 'a list with val empty : 'a set = SET nil fun member (x: 'a, SET l: 'a set, equal : 'a * 'a-> bool):bool = case l of nil => false | y ::m => if equal(x, y) then true else member(x, SET m) end; Transcript: std_in:33.5-36.60 Error: pattern and expression in val rec dec don't agree (tycon mismatch) pattern: 'aU * 'aU set -> bool expression: 'aU * 'aU set * ('aU * 'aU -> bool) -> bool in declaration: member = (fn ( : 'aU, : 'aU set, : 'aU * 'aU -> bool) => ((case l of => | => ): bool)) Comments: The types given for the pattern and expression seem to be backwards. Owner: Status: open ---------------------------------------------------------------------- Number: 736 Title: declaration printing with OR pattern Keywords: patterns, OR, printing Submitter: Dave MacQueen Date: 3/13/93 Version: 0.94 Severity: major Problem: Binding created by OR pattern is not printed. Transcript: - val ([x]|_::x::_) = [1]; std_in:5.1-5.23 Warning: binding not exhaustive (:: (x,nil) | :: (_,:: (,))) = ... - Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 737 Title: Compiler bug: Instantiate:explore_tclass.5 Keywords: modules, signatures, instantiation Submitter: Alan Smaill, smaill@lfcs.ed.ac.uk Date: 3/22/93 SML/NJ Version: 0.93 Machine: sparc/unix Severity: critical Problem: compiler error Code: signature S0 = sig type t end; signature S1 = sig structure A : S0 end; functor F (X: S0) : S0 = (* result signature necessary *) struct open X (* necessary, "type t = X.t" won't do *) end; structure B = F(struct type t = unit end); (* must be defined by functor application *) functor G(structure Y: S1 sharing Y.A = B) = struct end; Transcript: - use "bug737.sml"; [opening a.sml] signature S0 = sig type t end signature S1 = sig structure A : ... end functor F : structure B : S0 Error: Compiler bug: Instantiate:explore_tclass.5 Comments: compiles OK under 0.75 Fix: (Pierre Cregut) In sigmatch.sml comment out (* val _ = if self then ( case oldEnv of SOME (env,sigenv,strs) => (* The meaning of this hack is the following: If the structure is a self but belongs to a functor then it may contain a useless and big INSTANCE used as an intermediate structure for open. This function destroys such instances and replace them by a dummy structure. *) let fun clrOpen n = ( case Array.sub(strs,n) of INSTANCE{path as _ :: _, ...} => if Symbol.eq(name_O,last path) then (Array.update(strs,n,ERROR_STR);clrOpen (n+1)) else clrOpen (n+1) | _ => clrOpen (n+1)) handle Array.Subscript => () val thinenv = ref Env.empty (* Note: it would be nice if Env.map gave also the symbol to the argument function *) val _ = Env.app (fn (name,_) => thinenv := Env.bind(name,Env.look(!env,name), !thinenv) handle Env.Unbound => ()) sigenv in env := Env.consolidate(!thinenv) ; clrOpen 0 end | NONE => ()) else () *) -------------------------------- It is more than a hack, it is a bug. In normal cases nothing happens, but if you use the result of such an object to make a sharing constraint, then the origin on which the hack has been done, will become the target of the study... ... and one will discover that there are dummy structures instead of real ones. So if there is a type exported, here t, this one will need the structure to find its definition (it is an OPENFORMtyc created in elabstr.sml by the function openStruct) and, as there is nothing, unexpected errors occurs. Well the conclusion is that a usefull optimization is now impossible :-( Pierre Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 738 Title: Compiler Error : [SparcCM.fetchindexl] Keywords: code generation Submitter: Ju:rgen Buntrock Date: 3/22/93 Version: 0.93 System: SPARCstation 2 (4/75) SunOS Release 4.1.2 64Mbyte Ram Severity: critical Problem: Compiler Error : [SparcCM.fetchindexl] Comments: The Compiler calls some times fetchindexl with (ImmedLab lab, Direct dst, Immed i) Fix: output from diff -c : *** ../src.org/sparc/sparc.sml Wed Jan 27 20:41:53 1993 --- sparc/sparc.sml Tue Feb 23 23:36:02 1993 *************** *** 496,501 **** --- 496,504 ---- emit_ld (r, REGrand tmpR1, dst); freeTmpReg tmpR1 end + | fetchindexl (ImmedLab lab, Direct dst, Immed i) = + loadAddr (lab, 2*(i-1), dst) + | fetchindexl _ = ErrorMsg.impossible "[SparcCM.fetchindexl]" (*storeindexl (x, y, z) stores a word: mem[y+2*(z-1)] <- x *) Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 739 Title: Need nonblocking IO Keywords: I/O, nonblocking Submitter: Ju:rgen Buntrock Date: 3/22/93 Version: 0.93 System: SPARCstation 2 (4/75) SunOS Release 4.1.2 64Mbyte Ram Severity: major Problem: I need non blocking IO. There is a usefull function in cfuns.c : ml_writei : (int * bytearray * int * int) -> unit but I need the number of Bytes written! Fix: I have wriiten a function ml_writeiraw : (int * bytearray * int * int) -> int output from diff -c : diff -c runtime/cfuns.c.org runtime/cfuns.c *** runtime/cfuns.c.org Wed Jan 27 20:41:17 1993 --- runtime/cfuns.c Mon Mar 22 18:05:10 1993 *************** *** 567,573 **** --- 567,593 ---- } /* end of ml_writei */ + /* ml_writeiraw : (int * bytearray * int * int) -> unit + * Write data from the given bytearray to the specified file, starting at the + * given offset. This routine is not guaranteed to write all the bytes. + */ + void ml_writeiraw (msp, arg) + MLState_ptr msp; + register ML_val_t arg; + { + int sts; + int fd = REC_SELINT(arg, 0); + char *buf = (char *)REC_SELPTR(arg, 1); + char *start = buf + REC_SELINT(arg, 2); + int nbytes = REC_SELINT(arg, 3); + + sts = write (fd, start, nbytes); + CHK_RETURN(msp, sts); + + } /* end of ml_writeiraw */ + + #ifndef HAS_WRITEV struct iovec { char *iov_base; *************** *** 1802,1807 **** --- 1825,1831 ---- FUNCTION (ml_readi, "readi"), FUNCTION (ml_write, "write"), FUNCTION (ml_writei, "writei"), + FUNCTION (ml_writeiraw, "writeiraw"), FUNCTION (ml_writev, "writev"), FUNCTION (ml_lseek, "lseek"), FUNCTION (ml_send_obd, "send_obd"), Owner: Status: obsolete ---------------------------------------------------------------------- Number: 740 Title: stat_file returns wrong time for symbolic links Keywords: stat_file, cfuns Submitter: Ju:rgen Buntrock Date: 3/22/93 Version: 0.93 System: SPARCstation 2 (4/75) SunOS Release 4.1.2 64Mbyte Ram Severity: major Problem: stat_file (in cfuns.c) returns the wrong time in case of an symbolic link. This happens while using sourcegroup. Fix: output from diff -c : diff -c runtime/cfuns.c.org runtime/cfuns.c *************** *** 909,915 **** --- 929,938 ---- int sts; if (OBJ_isBOXED(f)) + /* sts = lstat((char *)PTR_MLtoC(f), buf); + */ + sts = stat((char *)PTR_MLtoC(f), buf); else sts = fstat(INT_MLtoC(f), buf); Owner: John Status: fixed in 109.21 [new basis] ---------------------------------------------------------------------- Number: 741 Title: bug in readi (cfuns.c) Keywords: readi, cfuns Submitter: Ju:rgen Buntrock Date: 3/22/93 Version: 0.93 System: SPARCstation 2 (4/75) SunOS Release 4.1.2 64Mbyte Ram Severity: major Problem: bug in readi (cfuns.c) Fix: *** runtime/cfuns.c.org Wed Jan 27 20:41:17 1993 --- runtime/cfuns.c Fri Mar 5 01:46:00 1993 *************** *** 493,499 **** int nbytes = REC_SELINT(arg, 3); int n; ! DO_SYSCALL (read (fd, buf, nbytes), n); CHK_RETURN(msp, n); } /* end of ml_readi */ --- 493,499 ---- int nbytes = REC_SELINT(arg, 3); int n; ! DO_SYSCALL (read (fd, start, nbytes), n); CHK_RETURN(msp, n); } /* end of ml_readi */ Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 742 Title: ZMAGIC prefered to NMAGIC Keywords: runtime, export Submitter: Ju:rgen Buntrock Date: 3/22/93 Version: 0.93 System: SPARCstation 2 (4/75) SunOS Release 4.1.2 64Mbyte Ram Severity: major Problem: Only on suns export.c uses NMAGIC, but ZMAGIC is better. Comments: The cpp-macro N_TXTADDR which is defined in /usr/include/maschine/a.out.h uses _N_BASEADDR : #define _N_BASEADDR(x) \ (((x).a_magic == ZMAGIC) && ((x).a_entry < N_PAGSIZ(x)) ? \ 0 : N_PAGSIZ(x)) This depends on a_entry! Fix: Set E.a_entry before textstart = N_TXTADDR(E); output from diff -c : *** runtime/export.c.org Wed Jan 27 20:41:24 1993 --- runtime/export.c Tue Feb 23 21:16:05 1993 *************** *** 165,171 **** #endif #else #if defined(sun3) || (defined(SPARC) && !defined(MACH)) ! E.a_magic = NMAGIC; #else # if defined(NS32) E.a_magic = NS32GMAGIC; --- 165,171 ---- #endif #else #if defined(sun3) || (defined(SPARC) && !defined(MACH)) ! E.a_magic = ZMAGIC; #else # if defined(NS32) E.a_magic = NS32GMAGIC; *************** *** 190,195 **** --- 190,198 ---- E.a_machtype = M_SPARC; #endif + /* by jubu : */ + E.a_entry = startptr; + /* */ textstart = N_TXTADDR(E); #ifdef HPUX E.a_text = (int) CEIL((ETEXT+textstart),getpagesize())-textstart; *************** *** 251,257 **** --- 254,268 ---- # if defined(DYNIX) bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E)-N_ADDRADJ(E)) # else + # if defined(SUNOS) + if(E.a_magic = ZMAGIC){ + bulletproofWrite(filid,textstart+sizeof(E),E.a_text-sizeof(E)); + } else { + bulletproofWrite(filid,textstart,E.a_text); + } + # else bulletproofWrite(filid,textstart,E.a_text); + # endif # endif #endif !defined(SPARC) || !defined(MACH) && !defined(BSD386) bulletproofWrite(filid,datastart,E.a_data); ========================================== *** makeml.org Wed Jan 27 20:39:19 1993 --- makeml Tue Feb 23 21:41:36 1993 *************** *** 421,427 **** case $OPSYS in SUNOS|MACH) DEFS="$DEFS -DBSD -Dsun3" ! CFL="-n $F68881" ;; MORE) OPSYS=BSD --- 421,427 ---- case $OPSYS in SUNOS|MACH) DEFS="$DEFS -DBSD -Dsun3" ! CFL="-Bstatic $F68881" ;; MORE) OPSYS=BSD *************** *** 447,453 **** DEFS="$DEFS -DBSD -Dsun4" if [ $OPSYS = SUNOS ] then ! CFL="-n" fi MO=${MO-"../mo.sparc"} MODULE="$MODULEKIND"Sparc"$DEBUG" --- 447,453 ---- DEFS="$DEFS -DBSD -Dsun4" if [ $OPSYS = SUNOS ] then ! CFL="-Bstatic" fi MO=${MO-"../mo.sparc"} MODULE="$MODULEKIND"Sparc"$DEBUG" Owner: Status: obsolete ---------------------------------------------------------------------- Number: 743 Title: bus error on Sparc Keywords: bus error, crash, sparc Submitter: jont@uk.co.harlqn Date: 23/03/93 Version: SML of NJ version 0.93 System: Sun 4/330 with SunOS 4.1.1 Severity: major Problem: Bus error Transcript: SIGBUS 10: bus error stopped at 0x37b150: ld [%l0 + 0x8], %l1 ctype -> unit val print_ctype : ctype -> unit end structure App : APP = struct open System.PrettyPrint open A fun pp_ctype pps cty = ( begin_block pps INCONSISTENT 0; case cty of IntType => add_string pps "int" | UintType => add_string pps "uint" | BooleanType => add_string pps "boolean" | StringType => add_string pps "string" ; end_block pps ) fun print_std_out ppf = fn x => let val pps = mk_ppstream {linewidth = 60, flush = fn () => flush_out std_out, consumer = outputc std_out} in (ppf pps x; add_string pps "\n"; flush_ppstream pps) end val print_ctype = print_std_out pp_ctype end fun try (args : string list, env : string list) = let val t = A.IntType in App.print_ctype t end Transcript: % sml Standard ML of New Jersey, Version 0.93, February 1, 1993 val it = () : unit - use "bug.sml"; [opening bug.sml] structure A : sig datatype ctype con BooleanType : ctype con IntType : ctype con StringType : ctype con UintType : ctype end signature APP = sig val pp_ctype : System.PrettyPrint.ppstream -> A.ctype -> unit val print_ctype : A.ctype -> unit end structure App : APP val try = fn : string list * string list -> unit [closing bug.sml] val it = () : unit - exportFn ("try", try); % try [Increasing heap to 160k] uncaught exception UNDEFINED Fix: Hooks.clear should not smash prettyprinter hooks. This problem goes away(?) with 0.95. Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 745 Title: Prettyprinter produces bad output when printing records Keywords: printing, prettyprint, records Submitter: Peter F. Patel-Schneider (pfps@research.att.com) Date: 3/11/93 Version: 0.93 Severity: minor Problem: Prettyprinter produces bad output when printing records. Transcript: val it = CONCEPT {all_rules=[],input=And [],key=ref (),local_rules=[],name="THING", nd=Ndescription {incoherent=false,one_of=NONE,primitives=[],range=NONE,rrs=[],sas=[], tests=[]},primitive=Defined} : concept It should be something like: val it = CONCEPT {all_rules=[],input=And [],key=ref (),local_rules=[],name="THING", nd=Ndescription {incoherent=false,one_of=NONE,primitives=[],range=NONE,rrs=[],sas=[], tests=[]}, primitive=Defined} : concept Comments: The examples I have seen are all of this bug, which appears to be that the pretty printer does not take into account whether a field stretched over a line, so that what should be {a=a,b=b, c=ccccccccccccccc cccccc, d=d,e=e} comes out as {a=a,b=b, c=ccccccccccccccc cccccc,d=d,e=e} By the way, I think that you should not retreat to {a=a, b=b, c=ccccccccccccccc cccccc, d=d, e=e} Owner: Status: open ---------------------------------------------------------------------- Number: 746 Title: Compiler bug: PPVal.decon - constant datacon in decon Keywords: printing, datatypes, top level Submitter: Anindya Banerjee (banerjee@cis.ksu.edu) Date: 3/15/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sparc station / Unix Severity: minor Problem: See below Code: datatype foo = bar of unit | baz of int ; datatype zip = biz of unit; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "test.sml"; [opening test.sml] datatype foo con bar : unit -> foo con baz : int -> foo datatype zip con biz : unit -> zip val it = () : unit - bar (); Error: Compiler bug: PPVal.decon - constant datacon in decon <----***--- - baz 3; val it = baz 3 : foo - biz (); val it = biz () : zip Tests: bug746.{1,2,3}.sml Status: fixed in 0.97a (same as bug 759) ---------------------------------------------------------------------- Number: 747 Title: core dump on HPPA Keywords: crash, hppa Submitter: Torben Mogensen (torbenm@diku.dk) Date: 3/17/93 Version: 0.93 System: HP 9000/700 (snake) Severity: critical Problem: The following program causes core-dumps when run in SML/NJ 0.93 on a HP "snake" workstation, but runs fine in the SPARC version. Code: datatype Lam = VAR of int | AP of Lam * Lam | ABS of Lam datatype Env = ENV of (Lam * Env) list fun lookup (ENV en, n) = nth (en, n) fun krivine (VAR n, env, s) = let val (e',env') = lookup (env, n) in krivine (e', env', s) end | krivine (AP (e1, e2), env, s) = krivine (e1, env, (e2,env)::s) | krivine (ABS e, env, s) = pop (s,e,env) and pop ([],e,env) = true | pop (v::s,e,ENV en) = krivine (e, ENV (v::en), s) fun krivine0 e = krivine (e, (ENV []), []) val church3 = ABS (ABS (AP (VAR 1, AP (VAR 1, AP (VAR 1, VAR 0))))) val lamid = ABS (VAR 0) val church27 = AP (church3, church3) val churchbig = AP (church3, church27) val testexp1 = AP (AP (church27, lamid), lamid) val testexp2 = AP (AP (churchbig, lamid), lamid) local type time = System.Timer.time val timeofday : unit -> time = System.Unsafe.CInterface.c_function "timeofday" in fun timeit f x = let open System.Timer val t = start_timer() val rt = timeofday() val z = f x val rt' = sub_time(timeofday(),rt) val t' = check_timer t val ts = check_timer_sys t val tg = check_timer_gc t in (z,implode["non-gc user time: ",makestring t', " gc time: ", makestring tg, " system time: ",makestring ts,", real time: ", makestring rt',"\n"]) end end Owner: Status: obsolete ---------------------------------------------------------------------- Number: 748 Title: Top level "local" declarations cause a space leak Keywords: space leak Submitter: Richard O'Neill Date: 3/23/93 SML/NJ Version: 0.93 (with SML/NJ Library 0.1') Machine: NeXTstation, OS3.0 Severity: Major Problem: Top level "local" declarations cause a space leak. Code: One would imagine that the two code sequences given below were more-or-less equivalent if typed at the top level. However, in the second of the two, the space taken by the locally declared objects are never reclaimed. Code sequence 1: let open Array val arr = tabulate (32 * 1024, fn x => x) in sub (arr, 1024) end ; Code sequence 2: local open Array val arr = tabulate (32 * 1024, fn x => x) in val it = sub (arr, 1024) end ; Transcript: next_mach% sml-lib Standard ML of New Jersey, Version 0.93, February 15, 1993 with SML/NJ Library, Version 0.1+, March 4, 1993 val it = () : unit - (* We'll use calls to the garbage collector to show the heap growing. *) - val gc = System.Unsafe.CInterface.gc val gc = fn : int -> unit - (* First, we'll show that code sequence 1 is leak-free. *) - - let open Array val arr = tabulate (32 * 1024, fn x => x) = in sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 66% used (994440/1501008), 796 msec] val it = () : unit - let open Array val arr = tabulate (32 * 1024, fn x => x) = in sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 66% used (994464/1501272), 734 msec] val it = () : unit - let open Array val arr = tabulate (32 * 1024, fn x => x) = in sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 66% used (994476/1501252), 749 msec] val it = () : unit - (* First case clearly doesn't cause any space leak. *) - - (* Second, we'll show that code sequence 2 has leak problems. *) - - local open Array val arr = tabulate (32 * 1024, fn x => x) = in val it = sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 75% used (1125548/1493424), 843 msec] [Increasing heap to 5504k] val it = () : unit - local open Array val arr = tabulate (32 * 1024, fn x => x) = in val it = sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 79% used (1253796/1580392), 906 msec] [Increasing heap to 6144k] val it = () : unit - local open Array val arr = tabulate (32 * 1024, fn x => x) = in val it = sub (arr, 1024) end ; val it = 1024 : int - gc 1; [Major collection... 83% used (1384872/1666728), 953 msec] [Increasing heap to 6784k] val it = () : unit - (* That heap just keeps on grow'in. :( *) - ^D next_mach% Comments: (Andrew) The bug report submitted by O'Neill, about local declarations causing a space leak, seems to be fixed in 0.95. I suspect we had staleLvars problems in 0.93, and we rewrote that stuff in 0.94. Status: fixed in 0.95 ---------------------------------------------------------------------- Number: 749 Title: nonequality type identified as equality type Keywords: types, equality Submitter: Andrew Koenig (research!ark) Date: 3/24/93 Version: 0.93 Severity: major Problem: Code: signature EQTYPE = sig type T val eq : T * T -> bool end structure S: EQTYPE = struct type T = int -> int fun eq _ = false end No problem so far. Note that EQTYPE.T is not actually required to be an eqtype, because eq could be anything. Now: functor ProductEqTypeFUN ( structure t1 : EQTYPE and t2 : EQTYPE ) : EQTYPE = struct type T = t1.T * t2.T val eq = op= end SML-NJ accepts this without complaint, even though t1.T and t2.T are not required to be eqtypes. Thus I can now say: structure SS = ProductEqTypeFUN (structure t1 = S structure t2 = S) fun f x = x + 1 fun g x = x - 1 and now SS.eq((f, f), (f, f)) yields true and SS.eq((f, f), (g, g)) yields false. Owner: dbm Status: fixed in 109.21 ---------------------------------------------------------------------- Number: 750 Title: printing in src/build/index.sml Keywords: index Submitter: Brian Milnes and Gene Rollins Date: 3/25/93 Version: 0.93 Severity: minor Problem: >From revision 93 src/build/index.sml | printDec(FCTdec fbs) = let fun printFctExp (FCTfct{def,...}) = printStrexp def | printFctExp (VARfct{def=FCTvar{name=fname',...},...}) = print_entry(Symbol.name fname', fn()=> print "functor ") | printFctExp (LETfct(dec,fct)) = ( printDec dec; printFctExp fct) in (app (fn (FCTB{fctvar=FCTvar{name=fname,...}, def}) => (print_entry(Symbol.name fname, fn()=> print "functor "); printFctExp def)) fbs) end the print "functor " should be a say "functor ". Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 751 Title: prettyprinting with or-patterns Keywords: printing, prettyprint, patterns, OR Submitter: John Reppy Date: 3/25/93 Version: 0.93 Severity: minor Problem: Pretty-printing of top-level variables bound in or-patterns is broken. Code: Transcript: In Bill's version (0.94a + bug fix): Standard ML of New Jersey, Version 0.94a, February 19, 1993 val it = () : unit - val (a|a) = 1; val a = 1 : int - val ((a,b)|(a,b)) = (1,2); val a = 1 : int val b = 2 : int - val ([x]|_::x::_) = [1]; std_in:4.1-4.23 Warning: binding not exhaustive (x :: nil | _ :: x :: _) = ... val x = 1 : int - In 0.94 (binding is working, but nothing is printed): Standard ML of New Jersey, Version 0.94x, February 26, 1993 val it = () : unit - val (a|a) = 1; val a = 1 : int - val ((a,b)|(a,b)) = (1,2); - a; val it = 1 : int - val ([x]|_::x::_) = [1]; std_in:5.1-5.23 Warning: binding not exhaustive (:: (x,nil) | :: (_,:: (,))) = ... - x; val it = 1 : int - Comments: It looks like the bug fixes were installed in 0.94, so something else must have broken. The diff's between Bill's version and 0.94b are: diff -r src/print/ppdec.sml 94-bill/src/print/ppdec.sml 52a53 > | ORpat(p1, _) => ppBind p1 diff -r src/translate/mc.sml 94-bill/src/translate/mc.sml 81c81 < [pat1, pat2] --- > (orExpand pat1)@(orExpand pat2) Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 752 Title: Maxint problem Keywords: arithmetic, integers, literals, bounds Submitter: florent@research.att.com (Florent Guillaume) Date: 3/26/93 Version: 0.93, 0.94 System: sparc? Severity: major Problem: Maxint problem Transcript: ihnp4 $ sml Standard ML of New Jersey, Version 0.94a, February 19, 1993 val it = () : unit - val x = 0x3fffffff; val x = 1073741823 : int - val y = ~x; val y = ~1073741823 : int - x-y; val it = ~2 : int - Comments: The problem is in generic.sml. When doing a sub of two integers, there is no test for overflow (for a mysterious reason). The problem doesn't show on mips, which tests for overflow on every operation, but it shows on sparc. This means that no program running on sparc relies on the exception raised by sub... Fix: More precisely, in /usr/local/sml/93/src/cps/generic.sml the line 1185 should be changed from (M.sub(gpregbind w, gpregbind v, x''); to (M.subt(gpregbind w, gpregbind v, x''); Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 753 Title: pretty printer prints syntactically incorrect text Keywords: printing, prettyprint, error recovery Submitter: John Reppy Date: 3/27/93 Version: 0.93 Severity: minor Problem: The pretty printer prints a syntactically incorrect text in some error messages. Code: Transcript: lexer.sml:66.15-66.65 Error: operator and operand don't agree (tycon mismatch) operator domain: {kind:ViewBuffer.token_kind, space:int ref, text:string} operand: {kind:ViewBuffer.token_kind, space:int, text:'Z} in expression: token ({space=! space,kind=Symbol,text=s}) Comments: The text should be token ({space= !space,kind=Symbol,text=s}) since the sequence ``=!'' is a symbolic identifier. Owner: Status: open ---------------------------------------------------------------------- Number: 754 Title: compiling eXene with newconreps generates uncaught Nth exception Keywords: eXene, conreps Submitter: John Reppy (jhr@research.att.com) Date: 3/27/93 System(s) and Version: Compiler, version 0.93 SML/NJ Version: 0.93 Machine: All Severity: major Problem: Attempting to compile eXene with newconreps enabled produces an uncaught exception Nth in cpsopt. Code: Transcript: ... structure ScrollLayout : SCROLL_LAYOUT [opening composite/widget-set.sml] parse, 291 lines, 0.360000s semantics, 0.670000s translate, 0.110000s codeopt, 0.050000s convert, 0.050000s uncaught exception Nth - Comments: I think that the bug is occuring in makeSELECT in contract.sml. I turned on debugging (System.Control.CG.misc1), and it prints a "d" just before the exception. There are two calls to nth in Contract; the one in makeSELECT has a click "d" just before it (the other has a click "g"). - John Transcript: ... Contract: ggggggggeeeeggggfddd uncaught exception Nth - Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 755 Title: Compiler bug: DebugError:Static.locOfEvent bad APPev marking Keywords: Submitter: Bart Massey Date: 3/28/93 System(s) and Version: Compiler/Debugger SML/NJ Version: 0.93 Machine: Sun 4 SunOS 4.1.3 Severity: major Problem: smld error compiling source Code: Available on request -- about 200 lines It's difficult to trim, as I have no idea where to start. Transcript: I "usedbg" a bunch of sources into smld, then - usedbg "runaway-searchops.sml"; Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking - Note (for what it's worth) that the code compiles OK with "use", but dies at runtime with an uncaught exception (this is what I was trying to debug :-). Comments: First time I tried to use the debugger. Bummin' :-). Fix: As suspected, this bad APPev marking bug was due to a problem with marking of derived forms, in this case selectors (#). The fix is a small patch to elaborate/elabutil.sml: pleiades% diff ../../93/src/elaborate/elabutil.sml elaborate 99a100,102 > If no member of list is marked, mark the default case with loc of 0 > in order to keep debugger instrumenter happy; this case should never > be executed anyway. 105c108 < r :: (f (SOME left) rest) --- > r :: (f left rest) 107,109c110,111 < | f (SOME loc) nil = [rule (fn exp => MARKexp(exp,loc,loc))] < | f NONE nil = [rule (fn exp => exp)] < in f NONE --- > | f loc nil = [rule (fn exp => MARKexp(exp,loc,loc))] > in f 0 Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 756 Title: compiler loops Keywords: type checking, infinite loop Submitter: Bart Massey Date: 3/28/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sun 4 SunOS 4.1.3 Severity: minor Problem: compiler spins (in elaboration phase?) Code: val rec f = fn x => g x and g = fn x => f x; Transcript: The above declaration, when typed at the interactive environment, appears to cause the compiler to infinite-loop. Comments: Don't ask why anyone would type this. Fix: (Appel) Andrew sez "I fixed this bug in 0.96a. It was in the Eta phase. And aren't there some nice juicy eta-redexes in the example!" Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 757 Title: ml_connect_inet isn't implemented for AIX Keywords: aix, ml_connect_inet Submitter: Cliff Krumvieda, cliff@cs.cornell.edu Date: 4/12/93 System and Version: Runtime system, 0.93 SML/NJ Version: 0.93 Machine: IBM RS/6000, AIX 3.2 Severity: Major Problem: ml_connect_inet isn't implemented for AIX Code: See runtime/cfuns.c Transcript: None needed Comments: I had a distributed systems expert (Robert Cooper) look at ml_connect_inet, and he suggested the following (trivial) fix. It seems to work. Fix: ====================================================================== *** cfuns.c-dist Tue Feb 9 11:37:22 1993 --- cfuns.c Mon Apr 12 09:27:38 1993 *************** *** 463,469 **** struct sockaddr_in saddr; int fd, s, i, sts; ! #if defined(SUNOS) || (defined(BSD) && defined(MIPS)) || defined(NeXT) || defined(AUX) || defined(HPPA) DO_SYSCALL (socket(PF_INET, SOCK_STREAM, 0), fd); if (fd != -1) { saddr.sin_family = AF_INET; --- 463,469 ---- struct sockaddr_in saddr; int fd, s, i, sts; ! #if defined(SUNOS) || (defined(BSD) && defined(MIPS)) || defined(NeXT) || defined(AUX) || defined(HPPA) || defined(AIX) DO_SYSCALL (socket(PF_INET, SOCK_STREAM, 0), fd); if (fd != -1) { saddr.sin_family = AF_INET; Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 758 Title: newconreps confusion Keywords: newconreps Submitter: Nevin Heintze (nch@cs.cmu.edu) Date: 3/31/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: machine independent (have experienced problem on pmax/mach, hp/hpux, ...) Severity: minor/major (if you run into it, you can waste a lot of time working out what is going on!) Problem: The parity of the newconreps flag gets messed up when recompiling the compiler. Code/Transcript: The problem occurs when you make a new version of the compiler from scratch (using makeml/smlc/upto.all) e.g. makeml -hppa hpux8 -batch smlc < all mv upto.all upto.all1 upto.all1 < all mv *.mo ../mo.hppa makeml -hppa hpux8 The binary generated is such that the abstract syntax interface has an inconsistent representation. For example, fun f str = let val consumer = (fn str => output(std_out, str)) val ppcon = {consumer = consumer, linewidth=80, flush = System.Print.flush} val strm = open_string str val sce = System.Compile.makeSource("string", 1, strm, false, ppcon) val env = System.Env.staticPart (!System.Env.pervasiveEnvRef) val (ast, _) = System.Compile.parse(sce, env) in ast end; f "val x = 1"; generates the error: "Error: Compiler bug: PPVal.switch: none of the datacons matched". This error is generated during the printing of the result of f "val x = 1". No error is generated from val _ = f "val x = 1". The problem seems to be related to the newconreps flag. The default value of this flag is "false" and the flag is toggled to "true" during the compilation of the compiler (see line 5 of all). However, in upto.all, newconreps is initially "true", and so line 5 of the file "all" serves to toggle it to "false", and so the upto.all compiles the compiler with newconreps = "false", and this leads to an inconsistency. Comments: Thanks to David Tarditi and Greg Morrisett for helping to track this down. I ran into the bug because I was modifying the pervasives for the purpose of implementing a program analysis algorithm (using set based analysis techniques). Fix: Toggle the newconreps flag back to false at the end of all (so that the flag is initially false in upto.all), just before dumping core. That is, the last few lines of all should read: ~summary ^globalhandle ^newconreps ^dumpCore >upto.all Status: fixed in 0.96 (completely new batch compilation system) ---------------------------------------------------------------------- Number: 759 Title: A data constructor of type unit may fail to prettyprint. Keywords: printing, prettyprint, datatypes, data constructor Submitter: Jeff Lewis (jlewis@cse.ogi.edu) Date: 3/31/93 System: Compiler SML/NJ Version: 0.93 Machine: Sun 4, SunOS 4.1.2 Severity: minor, but annoying Problem: A data constructor of type unit may fail to prettyprint. Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - datatype foo = Foo of unit | Bar of int * foo; datatype foo con Bar : int * foo -> foo con Foo : unit -> foo - Foo; val it = fn : unit -> foo - Foo(); Error: Compiler bug: PPVal.decon - constant datacon in decon Comments: Yes, I do have a good reason for declaring the datatype that way ;-) Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 760 Title: inexhaustive match in cps/cpsprint.sml Keywords: matches Submitter: Lal George Date: 4/1/93 Version: 0.95 Severity: minor Problem: There is an inexhaustive match in cps/cpsprint.sml that could be fixed in 0.95 or the next version. Below is the diff. Fix: ================================================================ 76c76,77 < --- > | pureName P.fnegd = "fnegd" > | pureName P.fabsd = "fabsd" Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 761 Title: failure under A/UX 3.0 Keywords: a/ux Submitter: Espen Svennevik (esvennevik@cix.compulink.co.uk) Date: 4/3/93 System(s) and Version: SML/NJ Version: 0.93 Machine: Macintosh Quadra 700 running A/UX v3.0 Severity: critical Problem: core dumps on simplest sml program Code: # sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - fun f x = x; Memory fault - core dumped # Comments: I have compiled njml with GCC v2.1, GCC v2.3.1 and with the host compiler. The errors have been indentical. Smli compiles, and runs ok, with GCC v2.3.1. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 762 Title: elaboration of equality test loops Keywords: equality, infinite loop Submitter: Andrzej Filinski Date: 4/3/93 System(s) and Version: Compiler, 0.93 (February 15, 1993) Machine: all Severity: major Problem: Elaboration of equality test loops on monomorphic instances of recursively-defined type constructors. Transcript: - datatype 'a foo = FOO of 'a foo foo; datatype 'a foo con FOO : 'a foo foo -> 'a foo - fn (x:int foo) => x=x; (* hangs *) Comments: "fn (x:''a foo) => x=x" works. Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 763 Title: error message doesn't give the *right* number of arguments Keywords: type checking, error messages Submitter: Thomas Yan (tyan@cs.cornell.edu) Date: 4/7/93 Version: 0.93 Severity: minor Problem: error message doesn't give the *right* number of arguments Code: []:list Transcript: - []:list; std_in:0.0-0.0 Error: type constructor list has the wrong number of arguments: 0 Comments: ideally, the message would also give the *right* number of arguments. Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 764 Title: Maxint problem + crash Keywords: arithmetic, integers, literals, bounds, Maxint Submitter: florent@research.att.com (Florent Guillaume) Date: 3/19/93 Version: 0.94a, probably all System: all Severity: major Problem: Maxint problem + crash Transcript: Standard ML of New Jersey, Version 0.94a, February 19, 1993 val it = () : unit - val x = 0; val x = 0 : int - 0x1fffffff - x; uncaught exception Overflow - 1+1; (* or anything else *) Illegal instruction (core dumped) Comments: The fix bellow should take care of the overflow problem, but I have no idea why an illegal instruction was generated. The problem is the following : in cps/generic.sml, when emitting code for (k - x), there is a (k+k+2) generated, which is not handled by cps/convert.sml. The recurring problems with big integers will only be solved when we have an integer type that can handle 2^32 (or even 2^64 for alphas) (currently, the hack in cps/convert.sml is really horrible, and not adequate for cross compiling between architectures with different sizes of integers). Fix: In cps/convert.sml (line 617 for 0.95), replace | Lambda.INT i => ((i+i; c(INT i)) with | Lambda.INT i => ((i+i+2; c(INT i)) Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 765 Title: syntax inaccuracy (signature named "*") Keywords: syntax, parsing Submitter: Cregut Pierre Date: 4/19/93 Version: 0.93 Severity: minor Problem: Some signature expression only recognise ID instead of full ident (including * and = so I can't match a structure against signature * . What a mess !!) Code: Transcript: Comments: Fix: Here is the change for true SML purists ! < sign : ident (MarkSig(VarSig (sigSymbol ident),identleft,identright)) --- > sign : ID (MarkSig(VarSig (sigSymbol ID),IDleft,IDright)) 618c618 < | COLON ident (SOME(VarFsig (fsigSymbol ident))) --- > | COLON ID (SOME(VarFsig (fsigSymbol ID))) 628c628 < fsig : COLON ident (VarFsig (fsigSymbol ident)) --- > fsig : COLON ID (VarFsig (fsigSymbol ID)) Beware line numbers are probably wrong because I have modified the grammar for my own purposes. Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 766 Title: capture/escape space leak is back! Keywords: space leak, continuations Submitter: John H. Reppy Date: 4/14/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sparc (probably others) Severity: major Problem: The space leak in capture/escape has reappeared (bug #633). 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 89 yes 90 no 91 no 92 no 93 no 94 yes As a reminder, the simple example of this problem is the function select in CML. 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 Transcript: Running a modified version of this that forces GCs: Standard ML of New Jersey, Version 0.94x, February 26, 1993 val it = () : unit - [opening xxx] val select = fn : (unit -> 'a) -> 'a structure XX : sig val f : unit -> unit end val it = () : unit [Major collection... 99% used (4426300/4451764), 1550 msec] [Increasing heap to 12977k] [Major collection... 98% used (4428356/4480768), 1710 msec] [Increasing heap to 13129k] [Major collection... 98% used (4480384/4532448), 1780 msec] [Increasing heap to 13281k] [Major collection... 98% used (4532384/4584448), 1830 msec] [Increasing heap to 13433k] [Major collection... 98% used (4584384/4636448), 1910 msec] [Increasing heap to 13585k] [Major collection... 98% used (4636384/4688448), 1960 msec] [Increasing heap to 13737k] val it = () : unit - Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 767 Title: OR patterns in val bindings broken Keywords: patterns, OR Submitter: Appel Date: 4/22/93 Version: 0.95 System: all Severity: minor (unless you like OR patterns) Problem: OR patterns don't work in val bindings (but they work in matches (fn, fun, case)). Code: val (a|a) = 6 Transcript: Standard ML of New Jersey, Version 0.95y, March 26, 1993 - val (a|a) = 6; - a; std_in:3.1 Error: unbound variable or constructor: a Comments: Some problem in elaboration. Fix: Ask Zhong. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 768 Title: OR patterns and inline primops don't mix well Keywords: patterns, OR, inline, primops Submitter: Appel Date: 4/22/93 Version: 0.94 System: all Severity: minor (unless you like OR patterns) Problem: When the right hand side of a val binding is an inline primop, and the left hand side is an OR pattern, an impossible error occurs. Code: val (a|a) = Array.sub; Transcript: Standard ML of New Jersey, Version 0.95y, March 26, 1993 - val (a|a) = Array.sub; Error: Compiler bug: elabVB Comments: No one would do this; I detected the bug by reading the code. Fix: Instead of impossible "elabVB" in elabcore.sml, just put "pat". This will lose the inline property but it will get the job done in this very rare case. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 769 Title: Compiler bug: DebugError:Static.locOfEvent bad APPev marking Keywords: modules, functors, debugger Submitter: Brian Milnes Date: 4/27/93 Version: 0.93 (smld) Severity: major Problem: Compiler bug caused by usedb. Code: (in file foo.sml) functor Queue () = struct type 'a queue = 'a list * 'a list fun add_to_queue (v, (a, b)): 'a queue = (a, v :: b) end Transcript: usedbg "foo.sml"; Error: Compiler bug: DebugError:Static.locOfEvent bad APPev marking Fix: Tolmach has sent fix? Status: fixed in 1.03f ---------------------------------------------------------------------- Number: 770 Title: profiling broken in 0.93 on yacc Keywords: profiler Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 5/6/93 Version: 0.93 System: mipsb/riscos Severity: minor Problem: profiling broken in 0.93 on yacc Code: First, use sml93 to generate a "smlp"; use "yacc.sml" Profile.reset(); Main.doit(); Transcript: ..................... - Profile.reset(); val it = () : unit - Main.doit(); DATA/ml.grm, line 63: Error: eof encountered in action beginning here ! DATA/ml.grm, line 63: Error: eof encountered in action beginning here ! DATA/ml.grm, line 733: Error: syntax error found at EOF uncaught exception ParseError Comments: ml.grm is a correct grammar specification. Obviously the instrumenting code inserted by the profiler changed the original semantics of the source programs. [Lal George] This may be related to bug 734. Fix: check the build/prof.sml carefully. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 771 Title: Low order digits of Pi are wrong Keywords: float, pi Submitter: La Monte H. Yarroll Date: 5/13/93 System(s) and Version: SML/NJ 0.93 compiler SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: minor Problem: Low order digits of Pi are wrong. Code: >From src/boot/math.sml in the compiler sources: val PIo4 = 7.8539816339744827900E~1 val PIo2 = 1.5707963267948965580E0 val PI3o4 = 2.3561944901923448370E0 val PI = 3.1415926535897931160E0 val PI2 = 6.2831853071795862320E0 This line is probably inacurate too: val oneOver2Pi = 0.15915494309189533576888376337251486 Transcript: NA Comments: This is only accurate to the 15th decimal place, even though 19 places are quoted. I can't easily check oneOver2Pi beyond 15 decimal places--but it is correct that far. It may be worth a quick recalculate, if you can do it easily. I happen to remember Pi to 17 decimal places, so I noticed the discrepency. I checked (and augmented) my memory against a poster in our stairwell :-). Fix: val PIo4 = 7.853981633974483096E~1 val PIo2 = 1.5707963267948966192E0 val PI3o4 = 2.3561944901923449288E0 val PI = 3.1415926535897932385E0 val PI2 = 6.2831853071795864769E0 Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 772 Title: Numeric selection with index > 9 Keywords: records Submitter: Soren Christensen (schristensen@daimi.aau.dk) Date: 5/13/93 Version: 0.93 Severity: major Problem: # selector doesn't work when n is an integer > 9 Code: type U = int*int*int*real*int*string*int*int*unit*int*int*bool; fun p1 (x:U) = (#1 x); fun p2 (x:U) = (#2 x); fun p3 (x:U) = (#3 x); fun p4 (x:U) = (#4 x); fun p5 (x:U) = (#5 x); fun p6 (x:U) = (#6 x); fun p7 (x:U) = (#7 x); fun p8 (x:U) = (#8 x); fun p9 (x:U) = (#9 x); fun p10 (x:U) = (#10 x); fun p11 (x:U) = (#11 x); fun p12 (x:U) = (#12 x); Transcript: (* p10, p11, and p12 fails with: std_in:65.17-65.23 Error: operator and operand don't agree (record labels) operator domain: {10:'Y, '...Z} operand: U in expression: (fn {10=10,...} => 10) x *) Btw, the error message for #0 is quite strange: fun p1 (x:U) = (#0 x); std_in:66.18 Error: syntax error found at INT0 Status: fixed in 0.97a ---------------------------------------------------------------------- Number: 773 Title: Compiler bug after unbound structure symbol Keywords: error recovery Submitter: Andrew Appel Date: 5/13/93 Version: 0.95 Severity: minor Problem: Code: Transcript: Standard ML of New Jersey, Version 0.95y, March 26, 1993 - structure I=J; std_in:2.13 Error: unbound structure: J Error: Compiler bug: Stamps.stampToPersstamp Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 774 Title: aliased exceptions are pattern-matched in the wrong order Keywords: exceptions, scoping, matches Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 5/15/93 System(s) and Version: SML/NJ Version: 0.93 Machine: Sun4, SunOS 4.1.3 (though the bug is probably generic) Severity: major Problem: aliased exceptions are pattern-matched in the wrong order Transcript: - (raise Vector.Size) handle Vector.Size => 1 | Array.Size => 2 | _ => 3; val it = 2 : int (* huh? I expected `1' here *) - (raise Array.Size) handle Vector.Size => 1 | Array.Size => 2 | _ => 3; val it = 2 : int (* should also be `1' *) Here's another example due to Michael Vium and Sten Schmidt at TU Denmark: Standard ML of New Jersey, Version 1.05, July 21, 1994 [new runtime] - exception A; - exception B = A; - val one = case A of B => 1 | A => 2; val one = 2 : int Comment: [Andrew Appel] [This] is a problem in translate/mc.sml. Here's the problem: Suppose you have a functor definition functor F(exception A exception B val f: unit->string) = struct fun g() = f() handle A => "A" | B => "B" end Now, the compiler CANNOT know at compile time whether A and B are the same exception. Thus, in the match compiler can't know what to do, and must resort to a very simple, one-at-a-time test of all the possibilities. The old match compiler (pre-Aitken) got this wrong. It tested the name (symbol) of the exceptions, and if these were equal it assumed the exceptions were the same; and if not equal, it assumed different. This is potentially incorrect in each case. The new match compiler is evidently getting this wrong in a different way, as shown by: exception A exception B=A (raise A) handle A => "A" | B => "B" the result of evaluating this is "B"; it should be "A". I think what is happening is that mc.sml is assuming that A and B are different, and (therefore) it is permitted to test for B before testing for A. What you must do is assume that two exception constructors (whose type is the same but which are otherwise different) are NEITHER equal nor unequal. Can this be fixed without undue difficulty? ---------------- [Peter Sestoft] Probably the match compiler optimizes exception matches too eagerly. An exception match must be implemented as a linear sequence of comparisons of `exception names' (string refs in SML/NJ). Owner: Status: open ---------------------------------------------------------------------- Number: 775 Title: calls of print in build/index.sml should be say Keywords: index, printing Submitter: Gene Rollins (rollins+@POP.CS.CMU.EDU) Date: 5/17/93 Version: 0.93 Severity: minor Problem: The file build/index.sml has two calls to print that should be changed to calls to say. Please change this in 0.95. thanks....gene Fix: 161c161 < print_entry(Symbol.name fname', fn()=> print "functor ") --- > print_entry(Symbol.name fname', fn()=> say "functor ") 166c166 < (print_entry(Symbol.name fname, fn()=> print "functor "); --- > (print_entry(Symbol.name fname, fn()=> say "functor "); Status: fixed in 0.96 ---------------------------------------------------------------------- Number: 776 Title: cannot compile under gcc 2.3.3 Keywords: runtime, install Submitter: Stephen Sullivan. sullivan@mathcom.com Date: 5/8/93 System(s) and Version: SPARC 2, Sunos 4.1.1, gcc 2.3.3 SML/NJ Version: 0.93 Machine: SPARC 2, Sunos 4.1.1, gcc 2.3.3 Severity: minor, but will be critical under Solaris 2 Problem: cannot compile under gcc 2.3.3; must use cc. Comments: When I set USE_GCC="TRUE" in src/makeml, the makeml script uses gcc but then gets a "malloc 3" error and dies. When I use makeml as is, makeml uses cc and works OK. But soon I am converting to Solaris 2, on which there is no cc: I'll have to use gcc. How can I get this working with gcc? [jhr] The problem is that gcc is producing initialization code for C++, which calls malloc, and malloc doesn't coexist with the current runtime system. We should have a new runtime system in place by the end of the summer, which does not interfere with malloc, and compiles under gcc. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 777 Title: building on I386 under 386bsd Keywords: install, eXene, 386bsd Submitter: Olaf Wagner (wagner@luthien.in-berlin.de) Date: 5/16/93 Version: 0.93 System: I386/386bsd Severity: major Problem: trying to run the eXene X window toolkit under 386bsd, I discovered that in file runtime/cfuns.c the function ml_connect_inet has been ifdef'd out for all BSD systems except those running on MIPS architectures. Fix: In order to get eXene running on 386bsd, one simply has to add a `|| defined(i386bsd)', but probably this should be defined for other BSD systems, too. At least on 386bsd the socket calls work without further modifications. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 778 Title: smld can't load SourceGroup Keywords: Sourcegroup Submitter: La Monte H. Yarroll Date: 5/26/93 System(s) and Version: SML/NJ 0.93 compiler (debugger), SourceGroup 3.0 SML/NJ Version: 0.93 Machine: SparcStation, SunOS 4.1.3 Severity: minor Problem: smld can't load SourceGroup. Transcript: $ smld Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - use "sourcegroup/export.sml"; [opening sourcegroup/export.sml] [opening ../tools/sourcegroup/load.sml] val print'sigs = 2 : int val it = () : unit [opening ../tools/sourcegroup/local/System/getwd.sml] ./tools/sourcegroup/local/System/getwd.sml:31.26-31.50 Error: operator and operand don't agree (tycon mismatch) operator domain: string operand: string * string list in expression: execute (program,args) - ^D $ Comments: I built smld with "./mlmake -noshare -debug". The symbol "execute" under smld is just completely different from the same symbol in a plain sml-noshare. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 779 Title: val rec syntax overly restrictive Keywords: syntax, parsing, val rec Submitter: Jeff Lewis (jlewis@cse.ogi.edu) Date: 5/26/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: irrelevant Severity: pretty darn minor ;-) Problem: val rec syntax overly restrictive Code: The following should be accepted, but isn't: val rec foo = (fn x => x): int -> int The problem is in the grammar, parse/ml.grm line 435: rvb: opid constraint EQUAL FN match ( ... ) | rvb AND rvb ( ... ) This grammar allows no possibility of a type constraint on the expression following the EQUAL. However, on page 9 of The Definition, section 2.9: Syntactic Restrictions, under the fourth bullet, it states that the expr on the right of the EQUAL may be type constrained. Transcript: - val rec foo = (fn x => x): int -> int; std_in:2.15 Error: syntax error found at LPAREN Owner: Andrew Status: open ---------------------------------------------------------------------- Number: 780 Title: nested subtraction doesn't check for overflow Keywords: arithmetic, integerts, overflow Submitter: Mikael Pettersson (mpe@ida.liu.se) Date: 5/31/93 SML/NJ Version: 0.93 Machine: SPARCstation ELC, SunOS 4.1.3 Severity: major Problem: nested subtraction doesn't check for overflow Code: Transcript: - ~1073741825; val it = 1073741823 : int - ~1073741820 - (ord "5" - ord "0"); val it = 1073741823 : int - ~1073741820 - 5; uncaught exception Overflow Comments: The expression (~1073741820 - (ord "5" - ord "0")) is (roughly) what makeInt (in src/ml.lex) evaluates in its last iteration over the input string "1073741825". The failure to detect overflow here causes it to silently accept (some) out-of-range constants. Status: fixed in 1.01 ---------------------------------------------------------------------- Number: 781 Title: FP overflow exception kills sml Keywords: floats, overflow, crash Submitter: Nick Haines Date: 6/1/93 Version: 0.93 System: mipsl, mach specific Severity: major Problem: FP overflow exception kills sml 0.93. Code: Transcript: But FP overflow dies: > - val x = ref 1.0; > val x = ref 1.0 : real ref > - fun f () = (print (!x); print "\n"; x := (!x * 123.1E17); f ()); > val f = fn : unit -> 'a > - f (); > 1.0 > 1.231E19 > 1.515361E38 > 1.865409391E57 > 2.296318960321E76 > 2.82676864015515E95 > 3.479752196031E114 > 4.28357495331415E133 > 5.27308076752972E152 > 6.49116242482908E171 > 7.9906209449646E190 > 9.83645438325143E209 > 1.21086753457825E229 > 1.49057793506583E248 > 1.83490143806603E267 > 2.25876367025929E286 > 2.78053807808918E305 > > uncaught exception Overflow > - bogus signal not in ML: (8, 0xb) Comments: Fix: The change affects two files, MIPS.prim.s and exncode.c. It simply adds a call to a one-instruction assembly-language function during the signal handler. First this addition to the end of MIPS.prim.s: *** 622,624 **** --- 622,638 ---- /* this bogosity is for export.c */ .globl startptr startptr: .word __start + + /* re_enable_fp: + * When working in Mach on Decstations, floating-point exceptions send + * SIGFPE not just once but over and over for ever, which breaks SML. + * If we call this in the signal handler, it won't. Nick Haines 23-Apr-93 + */ + + .globl re_enable_fp + .ent re_enable_fp + + re_enable_fp: + mfc1 $atmp1, $f0 + j $31 + And then these inserts to exncode.c: *** 8,13 **** --- 8,18 ---- #ifdef MIPS #ifdef sony_news #include /* for EXC_OV */ + + #ifdef MACH + extern void re_enable_fp(void); + #endif + #else #ifndef SGI #include /* for EXC_OV */ *************** *** 96,101 **** --- 101,111 ---- struct sigcontext *scp; int sig, code; { + + #if defined(MIPS) && defined(MACH) + re_enable_fp(); + #endif + switch (sig) { #ifdef THINK_C case SIGTRAP: Owner: Status: not reproducible ---------------------------------------------------------------------- Number: 782 Title: mllex actions with YYBEGIN Keywords: mllex Submitter: Ryszard Kubiak, Institute of Computer Science of the Polish Academy of Sciences, Gdansk, Poland, panrk@halina.univ.gda.pl Date: 6/2/93 Apparently-To: sml-bugs@research.att.com System(s) and Version: mlyacc and mllex SML/NJ Version: 0.93 of Feb 15 Machine: Sparc ELC, SunOS, OpenWin Severity: minor but major for me Problem: mllex does not generate tokens if the action is accompanied by YYBEGIN Comments: please inform me if it is really a bug (the documentation is vague about the semantics of semantic actions, so one may only rely on their common sense) and if there is a way of overcoming it Code: This yacc's code reads and copies the tokens generated by the lex code below: --- %% %name tcalc %arg (dev) : outstream %pos int %term NL | SWITCH | TXT of string | EOF %nonterm Start | Input %eop EOF %% Start : Input (close_out dev) Input : (* empty *) () | Input TXT (output (dev, "TXT " ^ TXT ^ "\n")) | Input NL (output (dev, "NL" ^ "\n")) | Input SWITCH (output (dev, "SWITCH")) --- This lex's code operates on two start states. The "#" character switches between them. The SWITCH token is intended to be passed to the parser. In my application it is vital that the parser gets an extra token to separate different parts of the grammar processed. Without this SWITCH my grammar is hopelessly out of LALR(1) class. --- structure Tokens = Tokens type pos = interface.pos type svalue = Tokens.svalue type ('a,'b) token = ('a,'b) Tokens.token type lexresult = (svalue,pos) token val line = ref 0 val eof = fn () => Tokens.EOF(!line,!line) %% %header (functor tcalcLexFun(structure Tokens : tcalc_TOKENS)); %S EXPR; %% "#" => (Tokens.SWITCH(!line,!line); YYBEGIN EXPR; lex()); [^#\n]* => (Tokens.TXT(yytext,!line,!line)); \n => (Tokens.NL(!line,!line)); "#" => (Tokens.SWITCH(!line,!line); YYBEGIN INITIAL; lex()); [^#\n]* => (Tokens.TXT(yytext,!line,!line)); \n => (lex()); --- This is a simple njml loader to load the above code if stored in "tcalcy" and "tcalcl" files, respectively. You may need to customize the paths. The funtion p invokes the parser on two files. For example, if the input file contains aaaa # 4444 then p generates TXT aaaa NL TXT 4444 Note that SWITCH is missing. --- use "/home/njml/tools/mlyacc/base.sml"; use "tcalcy.sig"; use "tcalcl.sml"; use "tcalcy.sml"; structure tcalcLrVals = tcalcLrValsFun(structure Token = LrParser.Token); structure tcalcLex = tcalcLexFun(structure Tokens = tcalcLrVals.Tokens); structure tcalcParser = Join(structure ParserData = tcalcLrVals.ParserData structure Lex=tcalcLex structure LrParser = LrParser); fun print_error (s,_,_) = output(std_out, "Error in " ^ s ^ "\n"); fun p inp_name out_name = let val inp_file = open_in ("/home/rysiek/calc/testy/" ^ inp_name) val out_file = open_out ("/home/rysiek/calc/testy/" ^ out_name) val lexer = tcalcParser.makeLexer (fn i => input(inp_file,i)) in tcalcParser.parse (15, lexer, print_error, out_file) end; Status: not a bug ---------------------------------------------------------------------- Number: 783 Title: smld incompatible with sourcegroup Keywords: debugger Submitter: Chris Ramming Date: 6/3/93 Version: 0.93 Severity: major Problem: Debugging ml, "smld", seems to be incompatible with sourcegroup. To reproduce the problem using sml93, first build the debugging version of ml (makeml -debug) named by convention "smld"; then using "smld", attempt to load sourcegroup by whatever method, for instance by 'use "load-all.sml"'. The load will fail almost immediately in file "date.sml" with a complaint about an operator/operand disagreement in expression 'execute(program,args)'. Owner: Status: obsolete ---------------------------------------------------------------------- Number: 784 Title: unnatural type error messages Keywords: types, type checking, error messages Submitter: Tim Freeman Date: 6/4/93 Version: 0.93 Severity: minor Problem: Type checker doesn't take programmer at his word. Code: Transcript: In version 0.93, this dialogue can happen: - fun foo (x:int) = (foo true; foo 1); std_in:0.0-0.0 Error: operator and operand don't agree (tycon mismatch) operator domain: bool operand: int in expression: foo 1 std_in:0.0-0.0 Error: pattern and expression in val rec dec don't agree (tycon mismatch) pattern: bool -> 'Z expression: int -> _ in declaration: foo = (fn x : int => (foo true; foo 1)) - Comments: I think the compiler should regard my explicit declaration of type int for x as correct, and complain about code that does not fit with it, instead of the other way around. In this example, at some point it should complain that true does not have type int. In the real example I'm dealing with now, there are many recursive calls to the function, and I am finding it difficult to discover which one has the wrong type, since the complier reports instead that some subset of the *correct* clauses are incorrect, and then it reports that all the explicit declarations I've put in are incorrect. Owner: Status: open (though not strictly speaking a bug) ---------------------------------------------------------------------- Number: 785 Title: makestring (on real numbers) gives wrong output Keywords: makestring, floats Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 6/8/93 Version: 0.96 System: mipsel/ultrix (perhaps on all machines) Severity: critical Problem: makestring (on real numbers) gives wrong output Code: makestring 0.0003; makestring 0.000786; makestring 0.0786; Transcript: - makestring 0.0003; val it = "0.003" : string - makestring 0.000786; val it = "0.786" : string - makestring 0.0786; val it = "0.786" : string - cos 1.57; val it = 0.796326710733202 : real (*** the correct output is the 0.00079... ***) Comments: This bug also affects all the real functions such as "cos", "sin" etc, because the output of these function applications will be printed out in ppval.sml via "makestring". The correct output should append the exponent at the end. Please look at the "real" function in boot/makestring.sml Version 0.93 handles this correctly. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 786 Title: overflow on ~1073741824 Keywords: arithmetic, integers, overflow, literals Submitter: Zhong Shao (zsh@cs.princeton.edu) Date: 6/8/93 Version: 0.96 System: mipsel/ultrix (perhaps on all machines) Severity: critical Problem: overflow on ~1073741824 Code: val x = ~1073741824; Transcript: - val x = ~1073741824; uncaught exception Overflow Comments: works in version 0.93. Possible caused by the new "makestring" function on integers. This number is the minimum integer that is used to implement the "mod" function etc. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 787 Title: redundant source files Keywords: config Submitter: Pierre Cregut Date: 6/10/93 Version: 0.93 Severity: minor (code cleanup suggestion) Problem: Similarities between util/sortedlist.sml and translate/mcset.sml suggest that one of these is redundant. Remarks: mcset.sml removed from all-files in 1.02, removed from directory in 1.03e Status: fixed in 1.03e ---------------------------------------------------------------------- Number: 788 Title: "open" reports an error (it should always work) Keywords: modules, open Submitter: Stefan Kahrs smk@dcs.ed.ac.uk Date: 6/14/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sun4 Severity: minor Problem: "open" reports an error (it should always work) Code: signature s=sig type a; val nil:a; val :: :int*a->a end; structure a:s = struct datatype a = nil | :: of int*a end; open a; Transcript: (Error message after the last declaration:) std_in:8.1-8.6 Error: pattern and expression in val dec don't agree (tycon mismatch) pattern: 'Z list expression: a.a in declaration: nil = nil std_in:8.1-8.6 Error: data constructor :: used without argument in pattern Comments: There are no patterns in the example, so the error message does not even make sense. I actually wrote this stuff to see what happens with a "derived form" like [1,2,3] after redefining :: and nil to some non-constructor operations. Thus I needed to un-constructor the two which is only possible with signatures and open. See also bug 847. Owner: dbm, Zhong Status: fixed in 109.27 [dbm, 4/4/97] ---------------------------------------------------------------------- Number: 789 Title: ML-style comment confuses preprocessor Keywords: comments, runtime, cfuns Submitter: David Ladd (ladd@graceland.ih.att.com) Date: 6/30/93 Version: 0.97 System: SGI Severity: minor Problem: runtime/cfuns.c, line 1754: ML-style comment confuses preprocessor (character constants need to be balanced, even in #ifdef'ed out code) Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 790 Title: System.Unsafe.SysIO.readi is wrong Keywords: readi, I/O Submitter: Cliff Krumvieda, cliff@cs.cornell.edu Date: 6/30/93 System and Version: Runtime system, 0.93 SML/NJ Version: 0.93 Machine: All but Macs Severity: Major Problem: System.Unsafe.SysIO.readi is wrong Code: See runtime/cfuns.c Transcript: None needed Comments: The code is obviously wrong. It looks like the programmer who did the Mac (THINK_C) port found the problem but didn't propogate the fix for everyone else. Fix: ====================================================================== *************** *** 646,656 **** int nbytes = REC_SELINT(arg, 3); int n; ! #ifdef THINK_C ! DO_SYSCALL (read (fd, start, nbytes), n); /* right!? */ ! #else ! DO_SYSCALL (read (fd, buf, nbytes), n); ! #endif CHK_RETURN(msp, n); } /* end of ml_readi */ --- 646,653 ---- int nbytes = REC_SELINT(arg, 3); int n; ! DO_SYSCALL (read (fd, start, nbytes), n); ! CHK_RETURN(msp, n); } /* end of ml_readi */ ====================================================================== Status: fixed in 0.97a (also bug #741) ---------------------------------------------------------------------- Number: 791 Title: sourcegroups generates an illegal instruction Keywords: Sourcegroup Submitter: Lal George Date: 7/1/93 Version: 0.93 System: SGI Challenger, IRIX 5.0 Severity: major Problem: sourcegroups generates an illegal instruction. Transcript: (1)[17:49]mafia:/home/cpg/bin/sgi$ sml-sg Illegal instruction (core dumped) (1)[17:49]mafia:/home/cpg/bin/sgi$ ll total 18660 -rw-r--r-- 1 cpg 25612 Jun 30 16:46 core -rwxr-xr-x 1 cpg 4149248 Jun 30 13:09 sml -rwxr-xr-x 1 cpg 5357568 Jun 30 16:39 sml-sg (1)[17:49]mafia:/home/cpg/bin/sgi$ file core core: IRIX core dump of 'sml-sg' (1)[17:49]mafia:/home/cpg/bin/sgi$ Comments: This was brought to my attention by Carlos Puchol cpg@research.att.com The compiler will not build under IRIX 5.0, however, the sml image created under IRIX 4.0.5F runs fine and will load and export sml-sg. The exported image generates an illegal instruction! This even happens when sml-sg is built under IRIX 4.0.5F. Status: not important --- obsolete ---------------------------------------------------------------------- Number: 792 Title: "withtype" scoping is wrong Keywords: syntax, withtype, scoping Submitter: Stefan Kahrs smk@dcs.ed.ac.uk Date: 7/5/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: Sun4 Severity: minor Problem: "withtype" scoping is wrong. Code: abstype a = B withtype t = int with type t = bool end val x : t = 4; Transscript: type a type t = int type t = bool val x = 4 : t Comments: The type constructor t should be bound to bool, not to int. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 793 Title: open of unbound structure causes duplicate error messages Keywords: error messages, open, error recovery Submitter: John Reppy (jhr@research.att.com) Date: 7/11/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: any Severity: minor Problem: open of unbound structure causes duplicate error messages Code: open Foo; Transcript: Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit - open Foo; std_in:2.1-2.8 Error: unbound structure: Foo std_in:2.1-2.8 Error: unbound structure: Foo - In 109.19m, also generates a compiler bug: - tuse "bugs/bug793.sml"; [opening bugs/bug793.sml] bugs/bug793.sml:4.1-4.9 Error: unbound structure: Foo bugs/bug793.sml:4.1-4.9 Error: unbound structure: Foo Error: Compiler bug: ModuleUtil: strId uncaught exception exception Error raised at: util/errormsg.sml:51.14-51.19 elaborate/elabmod.sml:890.8 elaborate/elabmod.sml:1104.7 util/stats.sml:168.40 test/evalloop.sml:127.37 test/evalloop.sml:202.20-202.23 Test: bug793.sml Owner: dbm Status: fixed in 109.19m ---------------------------------------------------------------------- Number: 794 Title: exception Substring when printing real numbers Keywords: printing, floats Submitter: Lal George Date: 7/15/93 SML/NJ Version: 0.97 Machine: all Severity: major Problem: exception Substring when printing real numbers. Transcript: kisubi:$ $s/97/bin/sparc/sml Standard ML of New Jersey, Version 0.97, 11 June 1993 - 0.3; uncaught exception Substring Comments: As far as I can tell this occurs for real numbers between 0.0 and 1.0. Status: fixed in 1.02 ---------------------------------------------------------------------- Number: 795 Title: Compiler bug: elabDecl:open:FctBodyStr Keywords: modules, functors Submitter: Lawrence C Paulson Date: 7/20/93 Version: 0.93 Severity: major Problem: Compiler bug: elabDecl:open:FctBodyStr caused by functor definition with let form of structure expression on rhs. Code: functor Fun (Str: sig end) = let open Str in struct end end; Transcript: albatross: sml Standard ML of New Jersey, Version 0.93, February 15, 1993 val it = () : unit . . . Error: Compiler bug: elabDecl:open:FctBodyStr - Status: fixed in 1.05 (using Cregut's fix from 8/11/93) ---------------------------------------------------------------------- Number: 796 Title: partially applied functor in functor body Keywords: modules, functors, higher-order functors Submitter: Chris Colby, colby+@cmu.edu Date: 7/21/93 System(s) and Version: Compiler SML/NJ Version: 0.93 Machine: pmax Mach Severity: major Problem: The body of a functor cannot conain a partially-applied curried functor. Code: signature S = sig type t end functor F (A:S) (B:S) = struct type t = int end functor G () = struct functor H = F (struct type t = int end) end Transcript: (0.93) uncaught exception Subscript Transcript: (106) Standard ML of New Jersey, Version 106, November 1, 1994 [new runtime] - use "bug796.sml"; [opening bug796.sml] signature S = sig type t end functor F : addStr1: pos = 1, |strArray| = 1 Error: Compiler bug: addStr1 - Comments: Replacing "functor G ()" with "structure X" successfully compiles. This is what leads me to believe that it is indeed a bug and not me. My sincere apologies otherwise. Status: fixed in 107 (dbm) ---------------------------------------------------------------------- Number: 797 Title: error in example "fol" in mlyacc Keywords: mlyacc, example Date: 8/2/93 System(s) and Version: Solaris, 1.0.1 SML/NJ Version: 0.93 of Feb 15 Machine: Sparc ELC, SunOS, OpenWin Severity: minor Problem: lines not counted at lexing time - example 'fol' in 'mlyacc' subdirs Fix: replace 'next_line()' for 'next_line' in line 25, file 'fol.lex' Owner: Status: fixed in 109.27 ---------------------------------------------------------------------- Number: 798 Title: incorrect sharing violation error Keywords: modules, signatures, include, sharing Submitter: John Reppy (jhr@research.att.com) Date: 8/2/93 System(s) and Version: Compiler SML/NJ Version: 0.97 Machine: sparc Severity: major Problem: When building CML, the compiler reports a sharing violation that is incorrect. Code: (* this code causes the bug *) signature CONCUR_ML = sig type 'a event type thread_id type 'a cond_var type 'a chan end; (* signature CONCUR_ML *) signature INTERNAL_CML = sig datatype 'a queue_t = Q of {front : 'a list ref, rear : 'a list ref} include CONCUR_ML end; (* INTERNAL_CML *) structure CML : INTERNAL_CML = struct datatype 'a queue_t = Q of {front : 'a list ref, rear : 'a list ref} (* Per-thread descriptors *) datatype thread_id = TID of { (* thread ids *) id : int, done_comm : bool ref, (* set this whenever this thread does *) (* some concurrency operation. *) death_cond : unit cond_var } (* condition variables *) and 'a cond_var = COND of 'a cond_state ref and 'a cond_state = COND_unset of (thread_id * bool ref * 'a cont) list | COND_set of 'a (* channels *) datatype 'a chan = CHAN of { inq : (thread_id * 'a cont) chanq, outq : (thread_id * 'a * unit cont) chanq } withtype 'a chanq = (bool ref * 'a) queue_t (* events *) datatype abort_fn = NO_ABORT | ABORT of (unit -> unit) datatype 'a base_evt = BASE_EVT of { pollfn : unit -> bool, dofn : abort_fn -> 'a, blockfn : (bool ref * abort_fn * (unit -> unit)) -> 'a, abortfn : abort_fn } datatype 'a event = EVT of ('a base_evt list * bool) (* the boolean is true if one of the *) (* base events has an abort action *) | GUARD of (unit -> 'a event) end; (* CML *) signature RUN_CML = sig structure CML : CONCUR_ML end; (* RUN_CML *) functor RunCML (CML : INTERNAL_CML) : RUN_CML = struct structure CML : CONCUR_ML = CML end; (* functor RunCML *) signature CONCUR_IO = sig structure CML : CONCUR_ML end; (* CONCUR_IO *) functor ConcurIO (RunCML : RUN_CML) : CONCUR_IO = struct structure CML = RunCML.CML end; (* functor ConcurIO *) signature TRACE_CML = sig structure CML : CONCUR_ML structure CIO : CONCUR_IO end; (* TRACE_CML *) functor TraceCML ( structure CML : INTERNAL_CML and RunCML : RUN_CML and CIO : CONCUR_IO sharing CML = RunCML.CML = CIO.CML ) : TRACE_CML = struct open CML (* need to open INTERNAL_CML version before rebinding CML *) structure CIO : CONCUR_IO = CIO structure CML : CONCUR_ML = CML end; (* TraceCML *) abstraction CML : sig (* hide the internals, but preserve type equality *) structure CML : sig include CONCUR_ML sharing type thread_id = CML.thread_id and type chan = CML.chan and type event = CML.event end structure RunCML : RUN_CML structure CIO : CONCUR_IO structure TraceCML : TRACE_CML sharing CML = RunCML.CML = CIO.CML = TraceCML.CML end = struct structure CML = CML structure RunCML = RunCML(CML); structure CIO = ConcurIO(RunCML); structure TraceCML = TraceCML( structure CML = CML and RunCML = RunCML and CIO = CIO); end; (* CML *) Transcript: /usr/local/sml/97/bin/sparc/sml Standard ML of New Jersey, Version 0.97, 11 June 1993 - use "bug"; [opening bug] signature CONCUR_ML = sig type 'a event type thread_id type 'a cond_var type 'a chan end signature INTERNAL_CML = sig datatype 'a queue_t con Q : {front:'a list ref, rear:'a list ref} -> 'a queue_t type 'a event type thread_id type 'a cond_var type 'a chan end structure CML : INTERNAL_CML signature RUN_CML = sig structure CML : ... end functor RunCML : signature CONCUR_IO = sig structure CML : ... end functor ConcurIO : signature TRACE_CML = sig structure CML : ... structure CIO : ... end functor TraceCML : bug:116.26-119.28 Error: structure sharing violation RunCML.CML # .CML bug:101.13-120.5 Error: structure sharing violation RunCML.CML # CML Status: fixed in 102 ---------------------------------------------------------------------- Number: 799 Title: bogus type name paths Keywords: types, type names, printing Submitter: Carl Gunter Date: 7/13/93 Version: 0.93? Severity: minor Problem: Bogus path names (starting with ?) are displayed in types. Code: (* Set.sml *) (* The SET signature adds various operations to the ORD_SET signature from the SML/NJ library *) signature SET = sig include ORD_SET val subset : (set * set) -> bool val mkset : (item list) -> set end (* The functor Set extends the functor BinarySet from the library to include various new functions by which the SET signature extends the ORD_SET signature *) functor Set(K : ORD_KEY) : SET = struct structure BinarySet = BinarySet(K) open BinarySet fun subset(a,b) = ((app (fn x => find(a,x))); true) handle NotFound => false fun mkset [] = empty | mkset (h::t) = add ((mkset t), h) end -------------------------------------------- structure Atom = struct datatype atom = Atom of int; type ord_key = atom fun cmpKey (Atom i, Atom j) = if i=j then LibBase.Equal else if i set val add : set * item -> set val find : set * item -> item val peek : set * item -> item option val member : set * item -> bool val delete : set * item -> set val numItems : set -> int val union : set * set -> set val intersection : set * set -> set val difference : set * set -> set val listItems : set -> item list val app : (item -> 'a) -> set -> unit val revapp : (item -> 'a) -> set -> unit val fold : (item * 'a -> 'a) -> set -> 'a -> 'a val revfold : (item * 'a -> 'a) -> set -> 'a -> 'a val subset : set * set -> bool val mkset : item list -> set end functor Set : val it = () : unit - [opening Atom.sml] structure Atom : sig datatype atom con Atom : int -> atom eqtype ord_key val cmpKey : atom * atom -> LibBase.relation end structure AtomSet : SET val it = () : unit - AtomSet.mkset; val it = fn : ?.AtomSet.BinarySet.item list -> ?.AtomSet.BinarySet.set - Owner: dbm Status: fixed in 109.31 [dbm, 8/14/97] ---------------------------------------------------------------------- Number: 800 Title: bad definition of dec in profiling script Keywords: profiler, dec Submitter: Andreas (andreas@metasoft.com) Date: 7/15/93 Version: 0.93 Severity: major Problem: You defined the 'dec' function like the 'inc' function (both with 'i+1'). This killed all our attempts to use the profiling image because we use the 'inc' and 'dec' to do some lexical checking (count '(' and ')') Status: fixed in 1.02 ----------------------------------------------------------------------