[Bug debug/51902] lexical_blocks inside inlined_subroutines generate duplicate debug_ranges

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 18:04:54 UTC ---
Created attachment 26385
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26385
gcc47-pr51902.patch

Partial patch.

The following example shows it even better, there are 5 identical 3 item
ranges:

static int k;

static int
foo (int i)
{
  int q1 = i, q2 = i;
  {
    int q3 = i;
    {
      int q4 = i, q5 = i;
      {
int j = i + 42;
return k + (j > 14 ? j : i);
      }
    }
  }
}

int
main (int argc, char **argv)
{
  int c = argc;
  k = 2 * c;
  c = foo (c);
  return c;
}

IMHO it is impossible to handle this solely in dwarf2out.c, you don't know if
the begin/end notes for a block are adjacent to its BLOCK_SUPERCONTEXT or not.
The attached patch is an untested attempt to provide that info (on a
per-fragment basis).  If the stmt BLOCK given to add_high_low_attributes has
BLOCK_SAME_RANGE bit set and all blocks in its BLOCK_FRAGMENT_CHAIN have it set
as well, then you should be able to use the range of its BLOCK_SUPERCONTEXT (if
both stmt and BLOCK_SUPERCONTEXT (stmt) have the same length of fragment chain,
then the whole supercontext's range, otherwise some tail part of it).  And
recursively so.

I guess in order to avoid searching through the fragment chains all the time
we should clear BLOCK_SAME_RANGE if BLOCK_SAME_RANGE (BLOCK_FRAGMENT_CHAIN) is
clear (somewhere still during reorder_blocks or number_blocks).

And then the question is how to find the range in the .debug_ranges table
effectively.  Walking the whole table would be O(n^2), so have some hash table
that maps the BLOCK_NUM ints that have BLOCK_SAME_RANGE children (at least one)
to .debug_range offsets?