[Bug debug/36690] [4.3/4.4 Regression] .debug_line first line is behind the first instruction

["jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #3 from jakub at gcc dot gnu dot org  2008-07-10 12:01 -------
Created an attachment (id=15888)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15888&action=view)
gcc44-pr36690.patch

Unfinished patch which solves the testcase in this PR and a couple of other
problems, but still there are plenty of issues.

It adds goto_block field to edges, because sometimes an edge is the only place
that uses certain scope.  Consider say:
void bar (int);

void foo (int i)
{
  if (!i)
    bar (0);
  else
    {
      static int z = 5;
      goto f1;
    }
  bar (1);
f1:
  bar (2);
}
At -O0 -g we really should be able to put breakpoint on goto f1 and see the z
variable.  Another testcase I've been playing with is:
void
bar (int i)
{
}

void
foo (int i, int j)
{
  if (j)
    {
      bar (i + 1);
      goto f1;
    }
  bar (i + 2);
  goto f2;
f1:
  if (i > 10)
    goto f3;
f2:
  if (i > 40)
    goto f4;
  else
    goto f5;
f3:
  bar (i);
f4:
  bar (i);
f5:
  bar (i);
}

int
main (void)
{
  foo (0, 1);
  foo (11, 1);
  foo (21, 0);
  foo (41, 0);
  return 0;
}

Here IMNSHO at -O0 -g one should be able to step through all the gotos, so
there should be some instructions with the locations of the gotos.  With the
attached patch one goto gets a location in the assembly, but the rest don't. 
One problem
is that already the into_cfglayout pass does some optimizations I wouldn't
think are appropriate for -O0, like merging basic blocks.  That's e.g. where
the
goto_locus of goto f1; is gone.  Either we should prevent that kind of
optimization if (!optimize) and the edge has goto_locus, or e.g. could insert
a nop insn with goto_locus as INSN_LOCATOR and hope at -O0 nothing later on
optimizes that out.  Another problem is with the conditional branches.  For
them
I'm afraid we can't put goto_locus on the conditional jump.  If just one
edge has goto_locus and the other does not, at (!optimize) we could possibly
invert the condition and thus let the unconditional jump be the insn that
holds the goto_locus INSN_LOCATOR.  But for the case where both edges have
goto_locus, I think we should just insert an extra conditional jump, so that
there are two unconditional jumps, each with its goto_locus.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36690