GitLab

We collect variables introduced by the {...} part of a let-like record wildcard
pattern and do not warn if the user then doesn't actually use them.

The problem was that the codegen for foreign calls makes sure the stack
is 16-byte aligned on OS X by pushing some padding. In the case where the
foreign call is cdecl, that padding gets popped after the call, but if the
convention is stdcall then it doesn't generate any popping code at all.

However, this is incorrect because the stdcall only promises to pop the
arguments, not the padding. The fix is to generate code to pop the padding
(if any) on OS X.

Converted from a darcs patch from Max Bolingbroke:
    Fri Apr  1 11:39:49 BST 2011  Max Bolingbroke <batterseapower@hotmail.com>
      * Really zap case-binder occurrence info: solves #5028

./sync-all fetch

  Fetches remote changes from the "origin" for each sub-repo.  Useful
  before "./sync-all new".

  (Runs 'git fetch origin' on all sub-repos.)

./sync-all new

  Lists the new patches relative to "origin" for each sub-repo.
  You probably want to './sync-all fetch' first.

  (Runs 'git log origin..' on all sub-repos)

Use it like this

  ./sync-all -r http://darcs.haskell.org/ghc-git set-origin

to set the origin branches of all sub-repos to point to the appropriate
repo within the http://darcs.haskell.org/ghc-git tree.

We were not prioritizing the interaction of equalities in the worklist, because
pre-canonicalization solved the constraints one by one, in their arrival order.
This patch fixes this, so it's a generally useful improvement, mainly for
efficiency. It makes #4981 go away, although it's not a definite answer to the
cause of the problem. See discussion on Trac.

This patch just puts a better SrcSpan on the AbsBinds
produced by the type checker

(See Trac #3011.)

This just disables the coercion optimiser, mainly for measurements in the paper

This dumps a (one-line) listing of the size of the Core program,
just after tidying

This fixes a couple of duplicates that had crept in, and also
renumbers everything so that they are monotonically increasing
through the file.

The .hsc files aren't currently safe for cross-compilation on Windows:
    libraries\haskeline\.\System\Console\Haskeline\Backend\Win32.hsc:160
    directive "let" is not safe for cross-compilation

Here's a bit of erroneous code:

00000c5c <s1ad_info>:
     c5c:       8b 45 08                mov    0x8(%ebp),%eax
     c5f:       d9 46 03                flds   0x3(%esi)
     c62:       dd d9                   fstp   %st(1)
     c64:       d9 55 08                fsts   0x8(%ebp)
     c67:       89 c6                   mov    %eax,%esi
     c69:       c7 45 00 24 0c 00 00    movl   $0xc24,0x0(%ebp)
     c70:       f7 c6 03 00 00 00       test   $0x3,%esi
     c76:       75 ac                   jne    c24 <s1ac_info>

So we should be doing some ffrees before the jne.  The code that
inserts the ffrees wasn't expecting to do it for a conditional jump,
because they are usually local, but we have a late optimisation that
shortcuts jumps-to-jumps, and that can result in a non-local
conditional jump.

This at least fixes an instance of the bug that I was able to
reproduce, let's hope there aren't any more.

Previously, -ddump-cmmz was used to dump out the "Raw Cmm" right
before it gets passed to the backends, as well as all of the
intermediate phases in the new code generator.  Unfortunately,
there are a lot of intermediate phases, which means -ddump-cmmz
takes a very long time with -fnew-codegen for large programs,
even if you're only interested in the final result.

Here we split up -ddump-cmmz into -ddump-cmmz (now exclusively for
the new code generator) and -ddump-raw-cmm (for both code generation
paths.) The old flag was not documented in the manual, so hopefully
not too many people will be surprised by this change.

When allocating new objects on the heap, we previously returned
a CmmExpr containing the heap pointer as well as the tag expression,
which would be added to the code graph upon first usage.  Unfortunately,
this meant that untagged heap pointers living in registers might
be spilled to the stack, where they interacted poorly with garbage
collection (we saw this bug specifically with the compacting garbage
collector.)

This fix immediately tags the register containing the heap pointer,
so that unless we have extremely unfriendly spill code, the new pointer
will never be spilled to the stack untagged.

An alternate solution might have been to modify allocDynClosure to
tag the pointer upon the initial register allocation, but not all
invocations of allocDynClosure tag the resulting pointer, and
threading the consequent CgIdInfo for the cases that did would have
been annoying.

This fixes the Lint error, but still risks leaving stupid
let { x=y } bindings in the code.  But no time to fix that 
today.  (Leave the ticket open for that reason.)