Simon's Marktoberdorf Commits

1.  Tidy up the renaming story for "system binders", such as
dictionary functions, default methods, constructor workers etc.  These
are now documented in HsDecls.  The main effect of the change, apart
from tidying up, is to make the *type-checker* (instead of the
renamer) generate names for dict-funs and default-methods.  This is
good because Sergei's generic-class stuff generates new classes at
typecheck time.


2.  Fix the CSE pass so it does not require the no-shadowing invariant.
Keith discovered that the simplifier occasionally returns a result
with shadowing.  After much fiddling around (which has improved the
code in the simplifier a bit) I found that it is nearly impossible to
arrange that it really does do no-shadowing.  So I gave up and fixed
the CSE pass (which is the only one to rely on it) instead.


3. Fix a performance bug in the simplifier.  The change is in
SimplUtils.interestingArg.  It computes whether an argment should 
be considered "interesting"; if a function is applied to an interesting
argument, we are more likely to inline that function.
Consider this case
	let x = 3 in f x
The 'x' argument was considered "uninteresting" for a silly reason.
Since x only occurs once, it was unconditionally substituted, but
interestingArg didn't take account of that case.  Now it does.

I also made interestingArg a bit more liberal.  Let's see if we
get too much inlining now.


4.  In the occurrence analyser, we were choosing a bad loop breaker.
Here's the comment that's now in OccurAnal.reOrderRec

    score ((bndr, rhs), _, _)
	| exprIsTrivial rhs 	   = 3	-- Practically certain to be inlined
		-- Used to have also: && not (isExportedId bndr)
		-- But I found this sometimes cost an extra iteration when we have
		--	rec { d = (a,b); a = ...df...; b = ...df...; df = d }
		-- where df is the exported dictionary. Then df makes a really
		-- bad choice for loop breaker

I also increased the score for bindings with a non-functional type, so that
dictionaries have a better chance of getting inlined early


5. Add a hash code to the InScopeSet (and make it properly abstract)
This should make uniqAway a lot more robust.  Simple experiments suggest
that uniqAway no longer gets into the long iteration chains that it used
to.


6.  Fix a bug in the inliner that made the simplifier tend to get into
a loop where it would keep iterating ("4 iterations, bailing out" message).
In SimplUtils.mkRhsTyLam we float bindings out past a big lambda, thus:
	x = /\ b -> let g = \x -> f x x
		    in E
becomes
	g* = /\a -> \x -> f x x
	x = /\ b -> let g = g* b in E
	
It's essential that we don't simply inling g* back into the RHS of g,
else we will be back to square 1.  The inliner is meant not to do this
because there's no benefit to the inlining, but the size calculation
was a little off in CoreUnfold.


7.  In SetLevels we were bogus-ly building a Subst with an empty in-scope
set, so a WARNING popped up when compiling some modules.  (knights/ChessSetList
was the example that tickled it.)  Now in fact the warning wasn't an error,
but the Right Thing to do is to carry down a proper Subst in SetLevels, so
that is what I have now done.  It is very little more expensive.

include GMP's configure files in a src dist.

x.yy.DDMMYYYY should be x.yy.YYYYMMDD for unstable snapshots.

typo

fix for .hc files

Cleanup of the compilation pipeline.  Now the list of phases to run
for each filename is generated statically, rather than on-the-fly.

Things should be more robust; some nonsense combinations of flags and
input files are now thrown out.

Redo the sparc Ccall machinery, so as to correctly handle the case
where one or more of the args to a Ccall is itself a Ccall.  Prior to
the advent of the Stix inliner, this could never happen, but now it
does.

* backup files are only generated, if there is an old dependency file.

* if $Makefile is "-", print dependencies to STDOUT *without* creating
  a backup file.


*** MERGE with 4.08.1 ***

added newline at EOF of package files

Panic if we try to allocate more than a block's worth of memory in one
go.  No fix yet, but at least this is better than going into an
infinite loop at runtime.

- add wORD_SIZE		(size of an StgWord in bytes)
- add bLOCK_SIZE_W	(size of a storage manager block in words)

Add a constant definition for WORD_SIZE, the size of an StgWord in bytes.

Revert part of the previous change, which broke the build by
generating a PrelStable.hi with some bogus kind information in it.

Advised Windows users to read the Windows installation notes for GHC before
trying to build anything.

Pointed out that Windows users should read the GHC installation guide before
trying to build anything.

increase the repeat count; this bug is pretty fragile

Add test for handle finalization bug, fixed in
  1.60      +1 -2      fptools/ghc/lib/std/PrelHandle.lhs
  1.15      +4 -10     fptools/ghc/lib/std/PrelIO.lhs

Fix bug reported by Hannah Schroeter: reading a file lazily using
hGetContents and then closing it using hClose can cause the program to
fall over with a deadlock.

The reason is that when closing the file in lazyRead{Block,Line,Char},
we set the foreign object in the handle to nullFile__, which causes
the finalizer to run (at some point in the future).  The finalizer
takes the MVar in the handle, frees the contents, but never puts the
MVar back.  hClose then tries to take the MVar, and deadlocks.

The solution is not to set the foreign object to nullFile__ in the
first place; I'm not sure why it was done this way, and in fact it
leads to a memory leak.  hClose itself has a similar problem, leading
to a leak of the fileObject.

giving the version number when asked for is NOT an error, therefore
output now goes to stdout (cf. Coding Standards)

update documentation to reflect changes in the format of a package spec.

Sigh, change the package definition again.  We weren't making a
distinction between libraries which need a suffix tag
(eg. libHSstd_p), and those that don't (eg. libHSstd_cbits).

The package spec now has two components for libraries, hs_libraries
(tagged) and extra_libraries (untagged).  The ordering of these
components is important: we specify that hs_libraries are linked
before extra_libraries.  This sounds problematic if you want to link
some plain C libraries before some Haskell libs, but in these cases it
should be possible to create separate packages for the two libs and
specify the dependencies explicitly.

Some changes to the way FFI decls are handled:

  - a foreign export dynamic which returns a newtype of
    an Addr now works correctly.  Similarly for foreign label.

  - unlifted types are not allowed in the arguments of a foreign
    export.  Previously we generated incorrect code for these cases.

Newtypes in FFI declarations now work everywhere they should, as far
as I can see.

These changes will be backported into 4.08.1.

Strictfp-like behaviour is the default now, which can be switched off
via -fexcess-precision. (Has anybody a better name for this option?)

Fix EXTINFO_RTS.

Add EXTINFO_RTS and use it (same as EXTFUN_RTS for info tables).

Changed ERTSF_ to EXTFUN_RTS.

Removed ERTSF_ and used EXTFUN_RTS instead, which does the same thing.

Make sure we *don't* try to make hsc_dll (as it will be identical to hsc).

Add dll as a fully-fledged way.

Make gmp.dll in DLL_PEN.

Make sure DLL_NAME only has DLL_PEN prepended if DLL_NAME has already been
set, i.e. a DLL is really to be built.

What's the story, Rory?

   My name's not Rory. Owing to circumstances not fully understood, the RTS
   used to work DLLized, even though it was largely broken. Unfortunately,
   this was recently fixed.

What used to happen?

   The EF_ macro from StgMacros.h was used to refer to primops &c.

Why was this a Bad Thing?

   Because you need to use EDF_ when building with DLLs.

What was the result?

   primops such as divExactInteger were compiled as _divExactInteger, rather
   than __imp__div_Exact_Integer, so they didn't refer to the DLL routines.

How on earth did it work?

   I'm not sure, but somehow the code for the relevant routines got linked
   into the import libraries (e.g. libHSrts_imp.a), and were thus linked
   statically into the final binary.

So that explains why the import libraries (supposedly just containing stubs)
were larger than the DLLs they were stubbing, or the static libraries, for
that matter?

   Perhaps.

Golly!

   Indeed.

What caused this code leakage?

   That's what I don't know. Perhaps a bug in the Cygwin DLL-building tools?
   I've upgraded from B20.1 to 1.1 recently.

So, what's the hack, Mac?

   My name's not Mac. I added a new macro, ERTSF_, which uses DLL_IMPORT_RTS
   to make sure that the Right Thing is always done (because you mustn't
   make DLL references to RTS routines when compiling the RTS).

Thanks for the chat, Matt!

   <punch>

4.07->4.08

Fixed a version-o.

> => >

Updated instructions for Windows install to reflect reality as of v4.08.

Added -dll option for dll way, now a proper way.

Target dlls directly into DLL_PEN so that they don't get rebuilt all the time.

Gave driver access to bash for running system calls under Windows by writing
command out to a temp file, then sending that as the argument to "sh -". Sigh.
This is #ifdefed on mingw32_TARGET_OS; saner OSs just use system as normal.

Stop doing all system calls via "sh -c", as this messed up quoting.