On Mon, 2005-11-14 at 21:30 -0500, Daniel Jacobowitz wrote: > On Wed, Nov 09, 2005 at 07:19:45PM +0100, mathieu lacage wrote: > > While the debugging output looks quite correct at -O0, the -O2 output > > seems broken: > > 00000000 <main>: > > 0: 8d 4c 24 04 lea 0x4(%esp),%ecx > > 4: 83 e4 f0 and $0xfffffff0,%esp > > 7: ff 71 fc pushl 0xfffffffc(%ecx) > > a: 55 push %ebp > > b: 89 e5 mov %esp,%ebp > > d: 53 push %ebx > > e: 31 db xor %ebx,%ebx > > 10: 51 push %ecx > > 11: 83 ec 10 sub $0x10,%esp > > 14: 8d b6 00 00 00 00 lea 0x0(%esi),%esi > > > With this list of basic block boundaries as reported by the debugging > > information: > > ad: 0x0 > > ad: 0x11 > > > Clearly, 0x11 is not a bb boundary so we have a bug. Despite the fact
This was a bug in my dwarf2 reading code. I fixed it and this testcase works for me now. > No, not clear at all. Every place which could be the target of a jump > will be the start of a basic block, but you are not guaranteed that all > sequential basic blocks are combined. Probably either Jim's right and It would be nice if you could post an example where they are not combined. > it's related to the end of the prologue, or it's a different basic > block because of some artifact of inlining. This shouldn't present any > problem for a tool using the basic block information. Inlining or end-of-prologue do not seem to have an influence on this. It seems to actually work quite well. I will send an updated version of the patch in another email. Mathieu --
