GitLab

Make recent _hsc.c / cbits changes work (i.e., need to add . to the include path)

Adjustor code cleanup. Added code to generate Alpha adjustors.
The way we generate Alpha adjustors right now, it only works if the
wptr function (the stub function for the Haskell side, that is) takes
no argument other than the hptr (the Haskell closure to call)!  I believe
the same deficiency exists in the Sparc adjustors code.

Steps towards getting GHCi working on alpha-dec-osf3 --
Clean up ghci/ByteCodeItbls.lhs, and add code for generating
a jump instruction on alpha.

#include <string.h> for memcpy prototype.

NB: This commit renames some files.  In each of your build directories,
    you will need to:

	rm -f ghc/compiler/prelude/primops.txt
	rm -f ghc/compiler/prelude/primops.i
	rm -f ghc/lib/std/PrelGHC.hi-boot
	lndir ../fptools	# or wherever your CVS working directory is

The change:
Run PrelGHC.hi-boot through the preprocesor, as we already do primops.txt.

This commit introduces a new prefix, ".pp", which means "run through
preprocesor".  In a previous commit, I changed ghc/compiler/Makefile
to preprocess primops.txt into primops.i.  That is gone now.  We now
preprocess primops.txt.pp (a file in the CVS repository) into primops.txt
(a platform-dependent file, created at build time).  We also preprocess
PrelGHC.hi-boot.pp (a file in the CVS repository) into PrelGHC.hi-boot
(a platform-dependent file, created at build time).

The reason for using the preprocessor is because fewer primops are defined
if SUPPORT_LONG_LONGS is undefined.  SUPPORT_LONG_LONGS is undefined on
64-bit architectures such as the Alpha.

Changed

    # Add _hsc.c files to the cbits library
    SRCS += $(wildcard ../*_hsc.c)

(which didn't work because SRCS has already been pattern-matched and
substituted into other make variables to death by then) to

    # Add _hsc.c files to the cbits library
    C_SRCS += $(wildcard ../*_hsc.c)

Fixed assumption that int and HsInt are the same.

Change the generation of package.conf and package.conf.inplace, so that
-lbfd and -liberty are included when necessary.

its => it's (or as the saying goes, wibble)

Fixed: ExitException doesn't exist in __GLASGOW_HASKELL__ < 501,
so references to ExitException should be preprocessed out.

- have the toplevel exception handler propagate ExitExceptions, don't flag
  them as panics. i.e., when the dynamic exception handler catches a
  PhaseFailed{}, it throws an ExitException. The outer/topmost handler
  catches this (on a Win32 box, but not my other (Linux) box for some
  reason...), and maps it to a panic, which is not what you want.
- introduced the old 'Compilation had errors' message in case of a
  PhaseFailed{}; feel free to nuke that one (again).

Keep ghci.c out of C_SRCS on non-mingw plats

Full complement of sized Int/Word getter routines

Fix enough bugs/incompletenesses so that foreign import (static) works
fairly well on x86.

Still ToDo:
* f-i dynamic
* save/restore GC/thread context around calls
* stdcall support
* pass/return of 64-bit integral quantities on x86
* sparc implementation

wibble: add cast to keep gcc happy.

Make dependency generation work a little bit better
(stage1 goes through OK; yet to do a stage2, but
thought I'd commit before I hit the sack).

Only define i_CCALL iff bci_CCALL is defined in WithHc's ByteCodes.h

Haskell-side support for FFI (foreign import only).

Since doing the FFI necessarily involves gruesome
architecture-specific knowledge about calling conventions, I have
chosen to put this knowledge in Haskell-land, in ByteCodeFFI.

The general idea is: to do a ccall, the interpreter accumulates the
args R to L on the stack, as is the normal case for tail-calls.
However, it then calls a piece of machine code created by ByteCodeFFI
and which is specific to this call site.  This glue code copies args
off the Haskell stack, calls the target function, and places the
result back into a dummy placeholder created on the Haskell stack
prior to the call.  The interpreter then SLIDEs and RETURNs in the
normal way.

The magic glue code copies args off the Haskell stack and pushes them
directly on the C stack (x86) and/or into regs (sparc et al).  Because
the code is made up specifically for this call site, it can do all
that non-interpretively.  The address (of the C fn to call) is
presented as just another tagged Addr# on the Haskell stack.  This
makes f-i-dynamic trivial since the first arg is the said Addr#.

Presently ByteCodeFFI only knows how to generate x86 code sequences.

C-side support for FFI in GHCi (foreign import only).

Simplify the dependency analyser to use the Finder instead of doing
its own directory searching.

Turn the strictness analyser back on again.

Fix something that looks wrong in an attempt to get HEAD back on the
rails again, whilst trying to get the award for the highest
size-of-commit-message-to-number-of-lines-actually-changed ratio.

The problem is this: a constructor defined as

	data T = A !Int

will cause a DataCon wrapper to be generated like this:

	A = \x -> case x of x' { DEFAULT -> $wA x' }

but the strictness on $wA says that it is strict in its first field.
This is where the story gets a little hazy, but it seems that the
compiler (5.00.2) happily removes the extra case thinking that x is
going to get evaluated anyway, leaving us with

	A = \x -> $wA x

and the argument to A ends up not being evaluated at all.  Certain
other parts of the compiler make use of the evaluatedness of fields in
order to remove unnecessary cases, with the end result that we end up
trying to dataToTag# an unevaluated thing, and certain derived Eq
instances can give wrong results.  Phew.

Now, here's the bit I *don't* understand: I can only see the bug with
5.00.2, and only when the data type has more than one constructor:

	data T = A !Int  |  B

nevertheless, the HEAD compiler when bootstrapped displays symptoms of
a broken Eq instance, so I'm trying this fix to see if it helps.

The Attempted Fix: give the DataConId a fully-lazy strictness
signature.

Some 64-bit fixes for the new GC code.

oops, only import Exception.block when compiling GHCi (and we know
we're bootstrapping)

Give ghc yet more memory.

Example invocation of 'windres' was a bit off

Support LFNs

Give ghc more heap so it can bootstrap itself until the strictness
analyser works again.

Signification cleanup & rewrite of CmLink.

Fixes at least one bug: the PersistentLinkerState could sometimes get
out of step with the RTS's idea of which modules were loaded, leading
to an unloadObj failure when we try to unload the same module twice.
This could happen if a ^C exception is received in the middle of a
:load.

Fixed by keeping the part of the linker's state that must match up
with the RTS's internal state entirely private to CmLink, stored in a
global variable.  The operations in CmLink which manipulate this state
are now wrapped by Exception.block, and so are safe from ^C
exceptions.

use :set rather than :s

*now* UF_CCS isn't used anywhere.

(and it was wrong, too, which is why I wanted to get rid of it)

Temporarily add -H80M to options for some modules, until the strictness
analyser is working again.

UF_CCS was used in compiler/main/Constants.lhs

Remove the out-of-date "FAQ" about GHCi not having the :add command
(it does now).

GHC_INTERPRETER_DIR is unused

UF_CCS is unused

make -keep-hc-files and -keep-s-files work with --make

Add the --with-gcc story. Tidy up some typos.

Update for changes in Haskell 98: take, drop & splitAt now don't fail
on negative arguments.

Disable all strictness analysis in the HEAD compiler until such time
as we can figure out why the new analyser is not working correctly.
I realise this is a drastic measure, but all previous attempts to
either fix or work around the problem have failed.

If you are doing work which requires maxed-out performance, you may
want to revert the effects of this commit in your source tree.  The
compiler only generates wrong code under pretty obscure circumstances
(when compiling itself).  All other programs appear to work correctly
with the new analyser.

We hope this situation will not last for long.