------------------------
1.  Bug in import.   Status: fixed

Fix description:

Entry points were being returned in wrong order by importer module.
Changed module to return entry points in order in which modules are
supposed to be executed by loader.

Problem:

The following example shows what may be a bug in the compiler.  uim is a 
module that includes "strings" and another module "flagset".

When I compile and execute the main module as shown I get the following 
message

	uncaught exception: Notfound_Loader

If I add in an 'import "flagset";' just before the 'import "uim"' then the
exception doesn't happen and the program works.  In c/loader.sml is the line

		       val structs = map lookup sl

which has no exception handler.

A useful error message would be nice.  Conversely I don't think that I 
should really need to import the "flagset" as it is not used in the main
module but is imported just where it is used.

Regards

====== x.sml ==============

import "strings";
import "uim";

structure Main =
struct
	structure Strings' = Strings()
	open Strings'

	val say = outputc std_out

	val d = get_decimal("12345")

	val _ = say("value of d is " ^ makestring(d) ^ "\n");
end


======= uim.sml ===========

import	"strings";
import	"flagset";

import	"uim.sig";


functor UIM():UIM = 
struct
	structure Strings' = Strings()
	open	Strings'

	structure Flag = FlagSet()
	
	........
end
---------------------------------
2.  Compilation of pervasives fails.   Status: fixed

Fix description:

There was no overflow check on integer
negation.  This caused integer makestring to fail when given
MININT for the SML/NJ system (-1073741824).  This in turn
caused the sml2c compiler to fail when compiling the pervasives,
since it must print MININT at some point (the point where output
to perv.sml.c stopped).

Problem:

Dear David,
	I seem to be having some problems with your new version of sml2c.
It compiled fine (using Sun4-390 under SunOS 4.1.2), but it does not 
appear to be able to recompile the pervasive files from scratch. I need
to be able to do this so that I can alter the perv.sml file for my
parallel ML routines in the pervasive environment. Nor can it compile
the original perv.sml file that comes with the distribution. I tried to
go back to using the old version of sml2c to compile the perv.sml file,
but of course the new one tries to reference Inline routines that don't
exist in the old heap, and it's not possible to mix heaps either. 

	When I do try compiling the pervasives, with
	% sml2c -pervasives
the compilation proceeds as normal, getting as far as perv.sml. Then it
opens that, finds the typical warning messages for "match not exhaustive",
starts to produce the perv.sml.c file, and outputs most of it, down
to the statements:

r[10]=r10;
return(r12);
};}else{if((r12>= -2147483646)){r12=r12-2;
r0=r9>>1;
r12=r12>>1;
if(((r0

and then gets stuck. It sits there thinking to itself for ages, chewing
up more and more heap space but quite slowly, and eventually causes the
machine to crash. At first I thought it was a lack of memory; however,
I put swap space up to around 500Mb, with the main memory at 32Mb, and
I think this ought to be sufficient. Even more strangely, it never
seems to make any difference as to where the program ceases to output
the C code for perv.sml.c. That is, I can use either your perv.sml, or
my modified perv.sml, but it's always the same point in the generated
C code (though the size of the file differs). Unfortunately, I can't
patch the code together (from the given perv.sml.c at the point where
my partially generated perv.sml.c gets up to to the end) because there
are redeclarations of L variables :-<

	On the brighter side, it does seem to compile simple programs
without any trouble whatsoever, and the executables produced work fine.
Can you let me know what resources compiling the pervasives typically
uses (swap size, time) and the type of architecture and operating system
you've been using please? I'm most perplexed, and can see little reason
for it not to work, particularly as it generates so much of the code
before failing. Is it perhaps something to do with the size of the file
being produced, or some weird interaction with swapped out pages of
memory?

Cheers,

Peter Bailey
peterb@cs.anu.edu.au
