GCC Bugzilla Bug 14049

Here is a small C++ function.

  int foobar (int x_1)
  {
    static int i_1;
    char c_1;

    marker1 ();
    c_1 = x_1;
    i_1++;

    return 0;
  }

I compile with gcc -S -gdwarf-2.

With gcc HEAD2 2004-02-01 15:37:18 UTC, the block info is fine:

  .LBB2:
  .LBB3:
    .loc 1 10 0
    call _Z7marker1v
    .loc 1 11 0
    movl 8(%ebp), %eax
    movb %al, -1(%ebp)
    .loc 1 12 0
    incl _ZZ6foobariE3i_1
    .loc 1 14 0
     movl $0, %eax
  .LBE3:
  .LBE2:
    .loc 1 15 0
    leave
    ret

With gcc tree-ssa-200206190-branch 2004-02-05 12:45:13 UTC, the call to marker1
is outside the block for the function:

    .loc 1 10 0
    call _Z7marker1v
  .LBB2:
  .LBB3:
    .loc 1 11 0
    movl 8(%ebp), %eax
    movb %al, -1(%ebp)
    .loc 1 12 0
    movl __ZZ6foobariE3i_1, %eax
    incl %eax
    movl %eax, __ZZ6foobariE3i_1
    .loc 1 14 0
    movl $0, %eax
  .LBE3:
  .LBE2:
    .loc 1 15 0
    leave
    ret

Later on, gcc emits a DW_TAG_lexical_block for LBB3/LBE3.  With gcc
tree-ssa-branch, this does not cover the call to marker1.  Here is what "readelf
-w" says:

  # gcc HEAD
  DW_TAG_subprogram foobar
  DW_TAG_formal_parameter x_1
  DW_TAG_lexical_block 0x8048340 0x8048356
  DW_TAG_variable i_1
  DW_TAG_variable c_1

  # gcc tree-ssa
  DW_TAG_subprogram foobar
  DW_TAG_formal_paramater x_1
  DW_TAG_lexical_block 0x8048345 0x804835b
  DW_TAG_variable i_1
  DW_TAG_variable c_1

So the local variables i_1 and c_1 are inside the lexical block, and the lexical
block does not cover the first statement of foobar.

So if I do this:

  (gdb) break foobar
  (gdb) run
  (gdb) info locals

Or this:

  (gdb) break marker1
  (gdb) run
  (gdb) up
  (gdb) info locals

... then gdb cannot find the locals.

Created an attachment (id=5694) [edit]
Source code

Created an attachment (id=5695) [edit]
Good assembly code, gcc HEAD

Created an attachment (id=5696) [edit]
Bad assembly code, gcc tree-ssa

Created an attachment (id=5697) [edit]
Source code for a test case

Here is another test program for the same bug (I think it's the same bug).

The guts of the test case are:

  void
  do_block_tests ()
  {
    int cb = 12;

    {
      int foo;
      foo = 123;
      {
	int foo2;
	foo2 = 123;
	{
	  int foo;
	  foo = 321;
	}
	foo2 = 0;
      }
      foo = 0;
    }

    cb = 21;
  }

With both gcc HEAD and gcc tree-ssa, the dwarf-2 info looks like:

  DW_TAG_subprogram do_block_tests
  DW_TAG_variable cb
  DW_TAG_lexical_block .LBB2 .LBE2
  DW_TAG_variable foo
  DW_TAG_lexical_block .LBB3 .LBE3
  DW_TAG_variable foo2
  DW_TAG_lexical_block .LBB4 .LBE4
  DW_TAG_variable foo

The problem is that gcc tree-ssa generates bad LBB/LBE pairs that do not
include the first assignment to the local variable.

Created an attachment (id=5698) [edit]
Good assembly code, gcc HEAD

Created an attachment (id=5699) [edit]
Bad assembly code, gcc tree-ssa

I can confirm this.

This PR describes two distinct bugs.  I thought they were two manifestations of
the same bug, but I guess they are not.

The bug with block.cc has been fixed in gcc HEAD 2004-07-06 12:02:23 UTC.
The last time I noticed it was broken was with gcc HEAD 2004-06-19 07:27:UTC.

The bug with scope.c still happens with gcc HEAD 2004-07-06 12:02:23 UTC.

scope.c I think has to do with scope is removed by the time we get to RTL but I
could be wrong.

Subject: Re:  [3.5 regression] bad debug block info, dwarf-2, c++

Would it help if I narrowed the problem with scope.c down to a
single patch?  I could do that if you need it.

MEC, yes, if you could narrow down the problem to a single patch, we would know 
who to bug about this.

Subject: Re:  [3.5 regression] bad debug block info, 
 dwarf-2, c++

I checked again with gcc HEAD 20040824 and the bug in scope.c has
been fixed.  The bug in block.cc is also still fixed.

The gdb test suite is happy too.  This was manifesting as regressions
in gdb.mi/mi-var-block.exp and gdb.mi/mi2-var-block.exp.

I couldn't see the fixed results in my test bed because the gdb.mi/*.exp
tests got blinded by the new warning for "incompatible implicit
declaration of built-in function".  The tests themselves just got
fixed a few days ago.

So I think this PR can go to RESOLVED/FIXED now.

I don't think it would be worth my time to chase down the patch that
caused the bug or the patch that fixed it.

so closing as fixed.