add casArray# primop, similar to casMutVar# but for array elements
Tweak stg_casArrayzh as per Simon Marlow's suggestion.
Update stg_casArrayzh to conform to new CMM conventions.
Add PrimOp: casIntArray#.  Modify casMutVar# for 'ticketed' style.
Add PrimOp fetchAddIntArray# plus supporting C function atomic_inc_by.
Eliminate atomic_inc_by and instead medofiy atomic_inc.
In the non-threaded RTS, make *_barrier functions EXTERN_INLINE, not #define. (fixes #8077)
Really unload object code when it is safe to do so (#8039)

The next major GC after an unloadObj() will do a traversal of the heap
to determine whether the object code can be removed from memory or
not.  We'll keep doing these until it is safe to remove the object
code.

In my experiments with GHCi, the objects get unloaded immediately,
which is a good sign: we're not accidentally holding on to any
references anywhere in the GHC data structures.

Changes relative to the patch earlier posted on the ticket:
 - fix two memory leaks discovered with Valgrind, after
   testing with tests/rts/linker_unload.c
Only add -O to C compilations if there was -O on the command line

In 1e2b3780ebc40d28cd0f029b90df102df09e6827 I changed the option
ordering for C compilations.  A side effect was that -optc options
came before the automatic -O we were adding, which made it so that the
-debug RTS was getting optimised when it shouldn't have been.

Perhaps we shouldn't have automatic -O options added to C
compilations.  But that might cause problems for build systems that
are relying on the current behaviour, so I've made a minor change
instead: now C optimisation level == Haskell optimisation level.
Comments only

This comment is no loger true
Update release notes for GHC 7.8
minor bugfix to casIntArray# and fetchAddIntArray#
Remove DYNAMIC_GHC_PROGRAMS tests in the linker

The linker is usable even when GHCi is dynamically linked.  These
tests make the linker_unload test fail.
Strings and comments only: 'to to ' fixes

I'd still prefer if a native english speaker would check them.
Update email addresses
MkIface: Mention that #include now adds dependent files

Signed-off-by: Austin Seipp <aseipp@pobox.com>
MkIface: More specific comment about what forms the interface hash

Signed-off-by: Austin Seipp <aseipp@pobox.com>
MkIface: When printing the recomp reason, make clear only mtime is used

Signed-off-by: Austin Seipp <aseipp@pobox.com>
MkIface: Be consistent with do notation

Signed-off-by: Austin Seipp <aseipp@pobox.com>
Fix interface hashes including time stamp of dependent files.

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>