If you still have a problem after consulting this section, then you may have found a bug—please report it! See Section 7.3 for a list of things we'd like to know about your bug. If in doubt, send a report—we love mail from irate users :-!
(Section 6.13, which describes Glasgow Haskell's shortcomings vs. the Haskell language definition, may also be of interest.)
These events are always bugs in the GHC system—please report them.
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.
Note that this is less likely to happen if you are compiling with GHC 4.00 or later, since the introduction of the dynamically expanding heap.
This is a bug just as surely as a “panic.” Please report it.
If you think that GHC could have produced a better error message, please report it as a bug.
Almost surely not a problem. About some specific cases…
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.
For example: “…warning: `Foo' declared `static' but never defined.” Unsightly, but shouldn't be a problem.
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.
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.
If the linker complains about not finding _<something>_fast, then something is inconsistent: you probably didn't compile modules in the proper dependency order.
(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…)
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.