GitLab

We were searching the wrong part of the heap for dead objects, this
was broken by recent changes to the step structure: from-space is now
in step->old_blocks, not step->blocks.  Fortunately some assertions in
ProfHeap picked up the problem.

There was an integer overflow in the definition of LDV_RECORD_CREATE
when StgWord is 64 bits.

fixes #687, see comment for details.

  
For 32-bit float primtives like sinFloat#, we currently call the
double versions of the C library functions (sin(), cos() etc.).  It
seems more correct to call the float versions (sinf(), cosf() etc.).
This makes a difference on x86_64, I'm not entirely sure why, but this
way at least generates more consistent results and avoids extra
promotion/demotion instructions when calling these primitives.

atomicModifyMutVar# was re-using the storage manager mutex (sm_mutex)
to get its atomicity guarantee in SMP mode. But recently the addition
of a call to dirty_MUT_VAR() to implement the read barrier lead to a
rare deadlock case, because dirty_MUT_VAR() very occasionally needs to
allocate a new block to chain on the mutable list, which requires
sm_mutex.

Relax the restrictions on derived instances in the same way, so we
can write

	data MinHeap h a = H a (h a) deriving (Show)

Fixes assertion failures with STM and -debug.  Tim says:
Sorry, it's a problem in how nested transactions are handled in
non-SMP builds.  It'll bite when trying to commit a nested transaction
which has read from a TVar but not updated it.

The call to validate_and_acquire_ownership in
stmCommitNestedTransaction should be the same as that in
stmCommitNestedTransaction, i.e.:

  result = validate_and_acquire_ownership(trec, (!use_read_phase), TRUE);

When the RTS is idle, as detected by the timer signal, instead of
prodding capabilities from the signal handler (which is not guaranteed
to work - pthread_cond_signal() can't be called from signal handlers),
create a new thread to do it.

This patch is a slightly-unsatisfactory fix to desugaring unboxed
tuples; it fixes ds057 which has been failing for some time.

Unsatisfactory because rather ad hoc -- but that applies to lots
of the unboxed tuple stuff.