It happens. We try to supply reasonable `-H<n>' flags for
`ghc/compiler/' and `ghc/lib/', but GHC's memory consumption
can vary by platform (e.g., on a 64-bit machine).
Just say `make all EXTRA_HC_OPTS=-H<a reasonable number>' and see
how you get along.

"The compiler died with a pattern-matching error."

This is a bug just as surely as a "panic." Please report it.

"Some confusion about a value specialised to a type..." Huh???

(A deeply obscure and unfriendly error message.)
This message crops up when the typechecker sees a reference in an
interface pragma to a specialisation of an overloaded value
(function); for example, `elem' specialised for type `[Char]'
(`String'). The problem is: it doesn't know that such a
specialisation exists!
The cause of this problem is (please report any other cases...): The
compiler has imported pragmatic info for the value in question from
more than one interface, and the multiple interfaces did not agree
exactly about the value's pragmatic info. Since the compiler
doesn't know whom to believe, it believes none of them.
The cure is to re-compile the modules that re-export the
offending value (after possibly re-compiling its defining module).
Now the pragmatic info should be exactly the same in every case, and
things should be fine.

"Can't see the data constructors for a ccall/casm" Huh?

GHC "unboxes" C-call arguments and "reboxes" C-call results for you.
To do this, it {@em has} to be able to see the types fully;
abstract types won't do!
Thus, if you say `data Foo = Foo Int#'
(a cool "boxed primitive" type), but then make it abstract
(only `data Foo' appears in the interface), then GHC can't figure
out what to do with `Foo' arguments/results to C-calls.
Solutions: either make the type unabstract, or compile with `-O'.
With the latter, the constructor info will be passed along in
the interface pragmas.

"This is a terrible error message."

If you think that GHC could have produced a better error message,
please report it as a bug.

"What about these `trace' messages from GHC?"

Almost surely not a problem. About some specific cases...

Simplifier still going after N iterations:

Sad, but harmless. You can change the number with a
`-fmax-simplifier-iterations<N>' option (no space);
and you can see what actions took place in each iteration by
turning on the `-fshow-simplifier-progress'
option.
If the simplifier definitely seems to be "looping," please report
it.

"What about this warning from the C compiler?"

For example: "...warning: `Foo' declared `static' but never defined."
Unsightly, but not a problem.

Sensitivity to `.hi' interface files:

GHC is very sensitive about interface files. For example, if it picks
up a non-standard `Prelude.hi' file, pretty terrible things will
happen. If you turn on
`-fno-implicit-prelude', the
compiler will almost surely die, unless you know what you are doing.
Furthermore, as sketched below, you may have big problems
running programs compiled using unstable interfaces.

"I think GHC is producing incorrect code":

Unlikely :-) A useful be-more-paranoid option to give to GHC is
`-dcore-lint'; this causes a "lint" pass to
check for errors (notably type errors) after each Core-to-Core
transformation pass. We run with `-dcore-lint' on all the time; it
costs about 5% in compile time. (Or maybe 25%; who knows?)

"Why did I get a link error?"

If the linker complains about not finding `_<something>_fast', then
your interface files haven't settled -- keep on compiling! (In
particular, this error means that arity information, which you can see
in any `.hi' file, has changed.)

"What's a `consistency error'?"

(These are reported just after linking your program.)
You tried to link incompatible object files, e.g., normal ones
(registerised, Appel garbage-collector) with profiling ones (two-space
collector). Or those compiled by a previous version of GHC
with an incompatible newer version.
If you run `nm -o *.o | egrep 't (cc|hsc)\.'' (or, on
unregisterised files: `what *.o'), you'll see all the consistency
tags/strings in your object files. They must all be the same!
(ToDo: tell you what they mean...)

"Is this line number right?"

On this score, GHC usually does pretty well, especially
if you "allow" it to be off by one or two. In the case of an
instance or class declaration, the line number
may only point you to the declaration, not to a specific method.
Please report line-number errors that you find particularly unhelpful.