[Bug debug/55541] [4.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated
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
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.6/4.7/4.8 Regression] unable to see local variables due extra lexical block was generated
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
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
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))
13703finish_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
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.jj2012-11-19 14:41:16.0 +0100
+++ gcc/cp/decl.c2012-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
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 |
