[Bug exp/34203] New: [gdb/exp] Namespace variable found before using statement at end of block

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=34203

            Bug ID: 34203
           Summary: [gdb/exp] Namespace variable found before using
                    statement at end of block
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: exp
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test.c:
...
     1  namespace mod_a {
     2    int xxx = 10;
     3  }
     4  
     5  static void
     6  foo ()
     7  {
     8  }
     9  
    10  int
    11  main ()
    12  {
    13    {
    14      foo ();
    15      using namespace mod_a;
    16      foo ();
    17    }
    18  
    19    return mod_a::xxx;
    20  }
...
compiled with "g++ test.c -g".

Now try to print xxx at line 14:
...
$ gdb -q -batch a.out -ex start -ex "p xxx"
  ...
Temporary breakpoint 1, main () at test.c:14
14          foo ();
No symbol "xxx" in current context.
...

That's as expected.

Now comment out line 16, and re-compile.

Instead, we have:
...
Temporary breakpoint 1, main () at test.c:14
14          foo ();
$1 = 10
...

This happens here in using_direct::valid_line:
...
      return (decl_line <= curr_sal.line)
             || (decl_line >= boundary);
...

We've got decl_line == 15, and curr_sal.line == 14, so
"decl_line <= curr_sal.line" evaluates to false.

But boundary == 14, so "(decl_line >= boundary)" evaluates to true.

Using the fix from PR34202 comment 2:
...
-            || (decl_line >= boundary);
+            || (decl_line > boundary);
...
doesn't help.

The boundary line is calculated here in cp_lookup_symbol_via_imports:
...
  /* Due to a GCC bug, we need to know the boundaries of the current block      
     to know if a certain using directive is valid.  */
  symtab_and_line boundary_sal = find_sal_for_pc (block->end () - 1, 0);
...
so it seems to be the case that some workaround is misfiring.

-- 
You are receiving this mail because:
You are on the CC list for the bug.