GitLab

They are not used anywhere in the compiler.

The parallel upsweep is the parallel counterpart to the default
sequential upsweep. It attempts to compile modules in parallel by
subdividing the work of the upsweep into parts that can be executed
concurrently by multiple Haskell threads.

In order to enable the parallel upsweep, the user has to pass the -jN
flag to GHC, where N is an optional number denoting the number of jobs,
or modules, to compile in parallel, like with GNU make. In GHC this just
sets the number of capabilities to N.

An unbuffered handle is very slow to output to and there doesn't seem to
be any reason to have these handles unbuffered.

All values read lazily from the same BinHandle share the same mutable
offset variable (_off_r). If two such lazy values are simultaneously
evaluated, the two threads will step over each other when writing to
_off_r.

Fortunately, for BinMem handles, making lazyGet thread-safe is simple:
just use a fresh off_r variable when deferring the call to getAt.

For BinIO handles, a race condition still exists because IO handles
contain their own mutable file pointer variable that gets clobbered in a
similar way that _off_r would. But GHC doesn't use BinIO handles anywhere
so this particular issue could be ignored for now.

While we're at it, consolidate duplicate code into a helper function and
strictify a few arguments.

A forkM'd action cannot safely share a UniqSupply with its parent.

[ Originally I resolved this issue in another way: by atomically
  updating env_us in newUnique/newUniqueSupply. But I think this
  (equivalent) change is more sensible. ]

unsafeInterleaveIO is used instead of unsafeDupableInterleaveIO because
a mk_supply thunk that is simultaneously entered by two threads should
evaluate to the same UniqSupply.

The UniqSupply counter is now incremented atomically using the RTS's
atomic_inc().

To mitigate the extra overhead of unsafeInterleaveIO in the
single-threaded compiler, noDuplicate# is changed to exit early when
n_capabilities == 1.

388e14e2 unfortunately broke a subtle invariant in the code generator:
when generating code for an application, names may need to be
externalised, in case you're building against something external with
was built with -split-objs.

We were never externalising the ids of the applied functions. This means
if the libraries are split and we call into them, then the compiler
won't may not generate correct ids when making references to functions
in the library (causing linker failure).

I'm not entirely sure how this didn't break everything, but it certainly
caused several failures for a bunch of people. I had to fiddle with my
tree a little to make this occur.

This should fix #8166.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Apart from bumping build-dep version bounds, `ghc-cabal` is adapted to
some minor Cabal API changes, and `bin-package-db` is made aware of
Cabal's recently added AGPL licence support.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

The iOS simulator is essentially an iOS target but for an x86 machine
instead. It doesn't support the native code generator either, though.
Authored-by: Stephen Blackheath <...@blacksapphire.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

happy reads .y files with the system encoding, so keep Parser.y.pp ASCII.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

This restores the original behaviour that was broken accidentally during
the refactoring peformed via 4f764d06.

This has been broken effectively for all GHC 7.6.x releases.

Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

symbol_extras is only part of ObjectCode on certain platforms.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

This lead to the stage1 compiler calculating random iface hashes.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

We weren't considering 'msys' for the $OSNAME.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

This reverts commit 2e41f2fa.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

GHC >= 7.4 is needed to bootstrap.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

This brings them up to date with the changes in #8144.
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Fixes #8144.

Before, the modification time of e.g. #included files (and everything
that ends up as a UsageFile, e.g. via addDependentFile) was taken as
input for the interface hash of a module.

This lead to different hashes for identical inputs on every compilation.

We now use file content hashes instead.

This changes the interface file format.
You will get "Binary.get(Usage): 50" when you try to do an incremental
using .hi files that were created with a GHC 7.7 (only) older than this commit.

To calculate the md5 hash (`Fingerprint`) of a file in constant space,
there now is GHC.Fingerprint.getFileHash, and a fallback version
for older GHCs that needs to load the file into memory completely
(only used when compiling stage1 with an older GHC).
Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>