GitLab

of 'invalid ELF header'.

versions of Fedora. The INPUT command is use by libncursesw.so in
Fedora.

Fixes Trac #5141.  Thanks to Adam Megacz.

I'm not sure if this is the best way to fix this, but it fixes the
unreg build.

Fixes an unreg build failure. I've also now made these sorts of
dependencies order-only.

The flag no longer exists, but we always behave as if it had been used.

I don't know why these were left out.  I did the obvious
thing... I hope it's right!

This matters for constructors and field labels that
have a trailing hash (MagicHash language extension).

Also a small refactoring in how the verbosity flag is handled.

not protected by locks in the threaded RTS.  This moves the free lists
to the individual hash tables and removes the static variables.

Spotted by Marcin Orczyk <orczykm@dcs.gla.ac.uk>, thanks!  This could
definitely cause actual crashes.

This reverts commit 2ec79623.

This assignment rewriting pass subsumes the previous reload
sinking pass, and also performs basic inlining.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>

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

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

If we find one then we print an error message and fail.

If we aren't validating and mk/build.mk doesn't exist then boot
prints a warning, pointing at instructions for setting up mk/build.mk.

This avoids duplicating some logic around the build system.

otherwise some versions of gcc complain about a missing final newline.

The pinned_object_block is where we allocate small pinned ByteArray#
objects.  At a GC the pinned_object_block was being treated like other
large objects and promoted to the next step/generation, even if it was
only partly full.  Under some ByteString-heavy workloads this would
accumulate on average 2k of slop per GC, and this memory is never
released until the ByteArray# objects in the block are freed.

So now, we keep allocating into the pinned_object_block until it is
completely full, at which point it is handed over to the GC as before.
The pinned_object_block might therefore contain objects which a large
range of ages, but I don't think this is any worse than the situation
before.  We still have the fragmentation issue in general, but the new
scheme can improve the memory overhead for some workloads
dramatically.

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