[Bug c++/55541] New: unable to see local variables due extra lexical block was generated

[Bug c++/55541] New: unable to see local variables due extra lexical block was generated

[chihin.ko at oracle dot com]

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

             Bug #: 55541
           Summary: unable to see local variables due extra lexical block
                    was generated
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: chihin.ko@oracle.com


There is a regression present gcc4.4.4: the compiler 
generates a bogus lexical block marker in the debug info, more precisely 
between the parameters and the local variables of functions.  This is related 
to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg02111.html

This affect gdb/dbx behavior, that debugger users are not able to inspect local
variable value when stop at "}" line of a function, for detail, please refer to
gdb bugzilla

http://sourceware.org/bugzilla/show_bug.cgi?id=14850

for following test cast

int
main() {
    int i;
    i = 10;
}

if I stop at  } of main and print i, gdb gave error:
tarting program: /home/chko/core/g++/g45/a.out

Breakpoint 1, main () at t.cc:4
4           i = 10;
(gdb) p i
$1 = 0
(gdb) n
5       }
(gdb) p i
No symbol "i" in current context.
(gdb)

This is due to "i" was within DW_TAG_lexical_block:

< 1><0x00000025>    DW_TAG_subprogram
                      DW_AT_external              yes(1)
                      DW_AT_name                  "main"
                      DW_AT_decl_file             0x00000001 /tmp/t.cc
                      DW_AT_decl_line             0x00000003
                      DW_AT_type                  <0x00000059>
                      DW_AT_low_pc                0x08050990
                      DW_AT_high_pc               0x080509a4
                      DW_AT_frame_base            <loclist with 4 entries
follows>
                        [ 0]<lowpc=0x00000000><highpc=0x00000001>DW_OP_breg4+4
                        [ 1]<lowpc=0x00000001><highpc=0x00000003>DW_OP_breg4+8
                        [ 2]<lowpc=0x00000003><highpc=0x00000013>DW_OP_breg5+8
                        [ 3]<lowpc=0x00000013><highpc=0x00000014>DW_OP_breg4+4
                      DW_AT_GNU_all_call_sites    yes(1)
                      DW_AT_sibling               <0x00000059>
< 2><0x00000042>      DW_TAG_lexical_block
                        DW_AT_low_pc                0x08050996
                        DW_AT_high_pc               0x0805099d
< 3><0x0000004b>        DW_TAG_variable
                          DW_AT_name                  "i"
                          DW_AT_decl_file             0x00000001 /tmp/t.cc
                          DW_AT_decl_line             0x00000004
                          DW_AT_type                  <0x00000059>
                          DW_AT_location              DW_OP_fbreg -12
< 1><0x00000059>    DW_TAG_base_type
                      DW_AT_byte_size             0x00000004
                      DW_AT_encoding              DW_ATE_signed
                      DW_AT_name                  "int"

[Bug debug/55541] unable to see local variables due extra lexical block was generated

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |flamaros.xavier at gmail
                   |                            |dot com

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-11-30 09:05:34 UTC ---
*** Bug 43566 has been marked as a duplicate of this bug. ***

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-11-30
      Known to work|                            |4.1.2
   Target Milestone|---                         |4.6.4
            Summary|unable to see local         |[4.6/4.7/4.8 Regression]
                   |variables due extra lexical |unable to see local
                   |block was generated         |variables due extra lexical
                   |                            |block was generated
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.3, 4.7.2, 4.8.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-11-30 09:21:48 UTC ---
Confirmed.

If I enable any optimization level, like for example -Og on trunk, I get:

(gdb) start
Temporary breakpoint 1 at 0x4005a0: file t.C, line 5.
Starting program: /tmp/t 

Temporary breakpoint 1, main () at t.C:5
5       }
(gdb) p i
No symbol "i" in current context.

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-30 10:35:06 UTC ---
That is the result of
13701      /* Make it so that `main' always returns 0 by default.  */
13702      if (DECL_MAIN_P (current_function_decl))
13703        finish_return_stmt (integer_zero_node);
in C++ finish_function (and for C99 similarly):
  if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted
      && TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl)))
      == integer_type_node && flag_isoc99)
    {
      /* Hack.  We don't want the middle-end to warn that this return
         is unreachable, so we mark its location as special.  Using
         UNKNOWN_LOCATION has the problem that it gets clobbered in
         annotate_one_with_locus.  A cleaner solution might be to
         ensure ! should_carry_locus_p (stmt), but that needs a flag.
      */
      c_finish_return (BUILTINS_LOCATION, integer_zero_node, NULL_TREE);
    }

Both these add the stmts after the function body, which is usually just a
BIND_EXPR containing all the stuff from the source in its operand in a
statement list.
We'd need to arrange for this, if the whole function body so far is a single
BIND_EXPR, to stick it at the end of the sequence in the BIND_EXPR.

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-30 13:03:40 UTC ---
I've tried to do:
--- gcc/cp/decl.c.jj    2012-11-19 14:41:16.000000000 +0100
+++ gcc/cp/decl.c    2012-11-30 12:24:42.255349700 +0100
@@ -13700,7 +13700,27 @@ finish_function (int flags)
     {
       /* Make it so that `main' always returns 0 by default.  */
       if (DECL_MAIN_P (current_function_decl))
-    finish_return_stmt (integer_zero_node);
+    {
+      /* If there is so far just a single statement, BIND_EXPR
+         with the whole main function body in it, push
+         return 0 stmt at the end of its body instead of after
+         the BIND_EXPR, so that variables declared in the function
+         scope are still in scope on the return stmt.  */
+      tree bind = NULL_TREE;
+      if (TREE_CODE (cur_stmt_list) == STATEMENT_LIST)
+        {
+          tree_stmt_iterator i = tsi_start (cur_stmt_list);
+          if (tsi_one_before_end_p (i)
+          && TREE_CODE (tsi_stmt (i)) == BIND_EXPR)
+        {
+          bind = tsi_stmt (i);
+          vec_safe_push (stmt_list_stack, BIND_EXPR_BODY (bind));
+        }
+        }
+      finish_return_stmt (integer_zero_node);
+      if (bind)
+        BIND_EXPR_BODY (bind) = stmt_list_stack->pop ();
+    }

       if (use_eh_spec_block (current_function_decl))
     finish_eh_spec_block (TYPE_RAISES_EXCEPTIONS

which makes sure that the return 0; has the right locus (for C99 similar change
would be needed), unfortunately it doesn't fix this.
Unlike C, the C++ FE creates an extra BLOCK around the BLOCK with BLOCK_VARS i
in this case, supposedly for the argument scope, so DECL_INITIAL
(current_function_decl) is in C the block with i var, but in C++ a block whose
BLOCK_SUBBLOCK is block with i var.  While the return stmt with the above patch
still has correct block, it seems to be actually completely ignored in the end,
because what matters actually is epilogue_location (in 4.7 and earlier
epilogue_locator).  cfgexpand.c and expand_function_end now set
epilogue_location to the input_location, when outside of particular stmt
expansion, which doesn't have a block, and I assume that DECL_INITIAL is then
used.  So the question is, can the C++ FE (when?) get rid of the outermost
BLOCK and change DECL_INITIAL (perhaps during genericization or so) to the real
function body scope instead.

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
         AssignedTo|jason at gcc dot gnu.org    |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> 2012-12-05 16:22:15 UTC ---
I'm finding the LOCATION_BLOCK code somewhat opaque, and think that I should
take care of more recent regressions before diving into it too much, so I'm
going to put this aside for now.

I don't remember the rationale for the extra block, but changing
finish_function to strip it right away causes quite a few testsuite
regressions.

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-06 15:07:22 UTC ---
(In reply to comment #5)
> I'm finding the LOCATION_BLOCK code somewhat opaque, and think that I should
> take care of more recent regressions before diving into it too much, so I'm
> going to put this aside for now.
> 
> I don't remember the rationale for the extra block, but changing
> finish_function to strip it right away causes quite a few testsuite
> regressions.

Can you attach your patch anyway, both for future reference and to find out why
it causes testsuite regressions?  I'm really curious...

[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug debug/55541] [4.7/4.8/4.9 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.4                       |4.7.4

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 15:15:51 UTC ---
GCC 4.6.4 has been released and the branch has been closed.

[Bug debug/55541] [4.7/4.8/4.9/4.10 Regression] unable to see local variables due extra lexical block was generated

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.4                       |4.8.4

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This regressed with r144474 aka PR39267.  Honza listed in his
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01231.html
mail that C/ObjC already defined no_body_blocks and that java, fortran and ada
were wrong in not setting that flag.  But that misses the important case of the
C++/ObjC++ FEs, which still even today emit the body blocks.
So, either we need to revert the removal of the no_body_blocks support (or
revert it into body_blocks), or adjust the C++ FE to perhaps create the
body_blocks if the FE needs them, but drop them during genericization.

[Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34677&action=edit
gcc5-pr55541.patch

Untested fix (that cures the testcase).

[Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 34677 [details]
> gcc5-pr55541.patch
> 
> Untested fix (that cures the testcase).

Unfortunately it broke bootstrap, I'd have hoped it wouldn't affect code
generation at all.  Debugging now.

[Bug debug/55541] [4.8/4.9 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |5.0
            Summary|[4.8/4.9/5 Regression]      |[4.8/4.9 Regression] unable
                   |unable to see local         |to see local variables due
                   |variables due extra lexical |extra lexical block was
                   |block was generated         |generated

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk.

[Bug debug/55541] [4.8/4.9 Regression] unable to see local variables due extra lexical block was generated

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.5                       |4.9.3

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.

[Bug debug/55541] [4.9 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug debug/55541] [4.9 Regression] unable to see local variables due extra lexical block was generated

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55541

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4