New codegen failing test-cases

[Edward Z. Yang]

*you feel a sudden sense of deja vu*

Here is my current play on things:

    - I can probably get a devel2 build with the new codegen turned on for
      everything.  This list of errors is from that build.  However, this
      build was originally failing, so I'm going to do a fresh devel2
      build and see if I've just got some weird Franken-GHC set up.

    - I can't seem to get a devel1 build with the new codegen turned on
      for everything built: the first invocation to the stage2 compiler
      segfaults.

I've been debugging 4030, since I looked at it previously to resolve
the black hole problems.  Doing so has given me a sense of deja vu, but
I think the failure mode this time is different.  The resulting
executable segfaults with -O and does not segfault with -O -fno-full-laziness
(strangely enough, -O0 -ffull-laziness does not segfault).  The failure
crops up if you do -fnew-codegen or -fno-new-codegen.

In the debugger, I've tracked the bug down to this incorrect block of
assembly:

Dump of assembler code for function c2Po_info:
   0x08285ac4 <+0>:     mov    0x48(%ebx),%eax
   0x08285ac7 <+3>:     mov    0x4c(%ebx),%ecx
   0x08285aca <+6>:     mov    %eax,-0x4(%ebp)
   0x08285acd <+9>:     mov    %ecx,0x0(%ebp)
   0x08285ad0 <+12>:    add    $0x4,%ebp
   0x08285ad3 <+15>:    add    $0xfffffff8,%ebp
=> 0x08285ad6 <+18>:    jmp    0x8285ad8 <c2PT_entry>

which fails to initialize the top two elements of the stack after
increasing the stack by a word:

(gdb) pstk
0xb7a7d4c4:     0xb7a7f01c
0xb7a7d4c0:     0x5
0xb7a7d4bc:     0x7
0xb7a7d4b8:     0x8
0xb7a7d4b4:     0x8285d58 <c2M9_info>
0xb7a7d4b0:     0xb7a82db8
0xb7a7d4ac:     0x2065832e
0xb7a7d4a8:     0x2065832e
0xb7a7d4a4:     0xb7a82de4
0xb7a7d4a0:     0x45
0xb7a7d49c:     0xdeadbeef
0xb7a7d498:     0x82812e0 <c4i4_info>
0xb7a7d494:     0x2065832e
0xb7a7d490:     0x2065832e
0xb7a7d48c:     0x0
0xb7a7d488:     0x7a5d52b       <- bogus

But I don't know where c2Po_info is coming from; it's not in the C--
dump of the program itself, so I assume it's in some library (but
then why is it affected by optimizations?).  Can I easily get C-- dumps of all
the librarise?

I suspect that I should actually do the full (and not just fast) test suite
on the stage2-new-codegen build to squirrel out more of these optimization
bugs, since debugging a buggy stage2 compiler produced by a buggy stage1
compiler... does not seem like fun at all.

I might suspend this work until I'm back in town and we can have a chat in
person.  I guess I should put my repository somewhere :-)

Cheers,
Edward