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