New codegen failing test-cases

[Simon Marlow]

On 13/01/2011 19:29, Edward Z. Yang wrote:
> *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

Perhaps I'm misunderstanding, but the above code looks fine (if a bit 
stupid).  It looks like this C--:

      x = W_[R1 + 0x48]
      y = W_[R1 + 0x4c]
      Sp[-4] = x
      Sp[0]  = y
      Sp = Sp + 4
      Sp = Sp - 8

So you should end up with

       ...
Sp[4] [R1 + 0x4c]
Sp[0] [R1 + 0x48]

perhaps check what R1 points to?

> 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?

It must be in a library - this is why -fno-new-codegen doesn't affect 
it, because the library is already compiled.  You can grep for the 
symbol in the library .o files, and then compile the offending module 
with -ddump-cmm (the symbol name might change, so you might have to 
recompile and debug the program again to get the new symbol name).

Cheers,
	Simon



> 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
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users