GitLab

It was off-by-one

We used to just get
    ghc: panic! (the 'impossible' happened)
      (GHC version 6.13.20091128 for x86_64-unknown-linux):
        too few bytes. Failed reading at byte position 32753
with no indication of what was being parsed.

Also corrected a couple of line 0's to line 1

So ghc-pkg register/update takes input in UTF-8, and ghc-pkg dump
outputs in UTF-8.  Textual package config files in the package DB are
assumed to be in UTF-8.

And make the code simpler in the process!

Caution: Largely untested

In a stack overflow situation, stack squeezing may reduce the stack
size, but we don't know whether it has been reduced enough for the
stack check to succeed if we try again.  Fortunately stack squeezing
is idempotent, so all we need to do is record whether *any* squeezing
happened.  If we are at the stack's absolute -K limit, and stack
squeezing happened, then we try running the thread again.

We also want to avoid enlarging the stack if squeezing has already
released some of it.  However, we don't want to get into a
pathalogical situation where a thread has a nearly full stack (near
its current limit, but not near the absolute -K limit), keeps
allocating a little bit, squeezing removes a little bit, and then it
runs again.  So to avoid this, if we squeezed *and* there is still
less than BLOCK_SIZE_W words free, then we enlarge the stack anyway.

This fixes deriving Ord (), which previously failed with
  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 6.13.20091123 for x86_64-unknown-linux):
          TcGenDeriv:mk_FunBind

Makes it easier to do unregisterised validate runs

We can't depend on sources in a bindist, because we don't have the sources.

Also, make K mean 1024 rather than 1000, in RTS flags (similarly for M
and G).  The main reason I want to change it is that otherwise this
might be confusing:
  
exp3_8: error in RTS option -H4k: size outside allowed range (4096 - 18446744073709551615)

And I think the original reason for using 1000 instead of 1024,
worries about direct-mapped caches, is not an issue in this context
(even if you can find a direct-mapped cache these days).

This means we get the prog name in error messages from the flag parser