* [Bug debug/46724] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
@ 2010-11-30 14:37 ` krebbel at gcc dot gnu.org
2010-11-30 14:48 ` krebbel at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: krebbel at gcc dot gnu.org @ 2010-11-30 14:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Andreas Krebbel <krebbel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |s390x-ibm-linux
Priority|P3 |P2
Keywords| |wrong-debug
Host| |s390x-ibm-linux
Target Milestone|--- |4.6.0
Known to fail| |4.6.0
Build| |s390x-ibm-linux
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
2010-11-30 14:37 ` [Bug debug/46724] " krebbel at gcc dot gnu.org
@ 2010-11-30 14:48 ` krebbel at gcc dot gnu.org
2010-12-02 9:51 ` [Bug debug/46724] [4.6 Regression] " krebbel at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: krebbel at gcc dot gnu.org @ 2010-11-30 14:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #1 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2010-11-30 14:37:39 UTC ---
Compiling with
GCC 4.5.2 (gcc version 4.5.2 20101108 (prerelease) [gcc-4_5-branch revision
166433] (GCC))
GDB returns "<value optimized out>" for 'a2' everywhere in function 'f'.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
2010-11-30 14:37 ` [Bug debug/46724] " krebbel at gcc dot gnu.org
2010-11-30 14:48 ` krebbel at gcc dot gnu.org
@ 2010-12-02 9:51 ` krebbel at gcc dot gnu.org
2010-12-02 12:11 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: krebbel at gcc dot gnu.org @ 2010-12-02 9:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #2 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2010-12-02 09:51:17 UTC ---
Marked as 4.6 regression. The behavior of 4.5.2 isn't helpful either but it
doesn't return a wrong value as with 4.6.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (2 preceding siblings ...)
2010-12-02 9:51 ` [Bug debug/46724] [4.6 Regression] " krebbel at gcc dot gnu.org
@ 2010-12-02 12:11 ` jakub at gcc dot gnu.org
2010-12-16 5:39 ` aoliva at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-02 12:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2010.12.02 12:11:48
CC| |aoliva at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-02 12:11:48 UTC ---
I guess one option would be:
1) allow DECL_DEBUG_EXPR even on RESULT_DECL (i.e. not use VAR_DECL_CHECK
there)
2) when creating function_result_decl in assign_parms_augmented_arg_list,
either don't mark that artificial PARM_DECL with DECL_IGNORED_P but
DECL_NAMELESS and put it into DECL_ARGUMENTS (but then it might confuse
debuggers), or create a separate artificial DECL_NAMELESS DECL_BY_REFERENCE
variable which will be put into outermost BLOCK.
3) in assign_parms, after assign_parm_setup_reg initializes it, we could
emit a DEBUG_INSN for this artificial variable, equating it to the
artificial
PARM_DECL's DECL_RTL
4) and set DECL_DEBUG_EXPR of the RESULT_DECL to this artificial VAR_DECL
The DECL_BY_REFERENCE thingie is there because var-tracking doesn't VALUE track
aggregates, so we just want to track its address.
Alex, what do you think about this?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (3 preceding siblings ...)
2010-12-02 12:11 ` jakub at gcc dot gnu.org
@ 2010-12-16 5:39 ` aoliva at gcc dot gnu.org
2010-12-17 6:14 ` aoliva at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-16 5:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #4 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-16 05:38:44 UTC ---
Considering that we create a decl for the implicit argument that holds the
address of <result>, perhaps the best approach would be to emit debug info for
that artificial decl. The initial implicit binding of argument variables to
their incoming locations should take care of the debug info for the artificial
parameter throughout the function, and the location of <result> could then be
given in terms of the artificial variable (dwarf calls). Does that sound
sensible?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (4 preceding siblings ...)
2010-12-16 5:39 ` aoliva at gcc dot gnu.org
@ 2010-12-17 6:14 ` aoliva at gcc dot gnu.org
2010-12-17 6:19 ` aoliva at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-17 6:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org
|gnu.org |
--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-17 06:13:57 UTC ---
Mine
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (5 preceding siblings ...)
2010-12-17 6:14 ` aoliva at gcc dot gnu.org
@ 2010-12-17 6:19 ` aoliva at gcc dot gnu.org
2010-12-17 8:55 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-17 6:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-17 06:19:30 UTC ---
Created attachment 22792
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22792
Patch I'm testing that fixes the bug
Here's what I meant. It does fix the bug at hand, and (surprisingly) we don't
end up emitting debug info for the artificial parameter. Tracking it is enough
to fix the location info for the variable that maps to the result. It looks
like this:
.byte 0x8 # uleb128 0x8; (DIE (0x15b) DW_TAG_variable)
.ascii "a2\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file
(../../gcc/testsuite/gcc.dg/guality/nrv-1.c)
.byte 0x10 # DW_AT_decl_line
.4byte 0xf5 # DW_AT_type
.4byte .LLST1 # DW_AT_location
.LLST1:
.8byte .LVL0 # Location list begin address (*.LLST1)
.8byte .LVL1-1 # Location list end address (*.LLST1)
.2byte 0x2 # Location expression size
.byte 0x72 # DW_OP_breg2
.byte 0 # sleb128 0
.8byte 0 # Location list terminator begin (*.LLST1)
.8byte 0 # Location list terminator end (*.LLST1)
The range covers the entire function. I haven't looked into why we don't
reduce the single-entry entire-function location list to a simpler location.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (6 preceding siblings ...)
2010-12-17 6:19 ` aoliva at gcc dot gnu.org
@ 2010-12-17 8:55 ` jakub at gcc dot gnu.org
2010-12-17 9:44 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-17 8:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-17 08:55:06 UTC ---
Ah, the trick is that you keep the artificial PARM_DECL out of DECL_ARGUMENTS
as it was and manually add it in var-tracking.
To avoid dropping the DECL_NAME test you could perhaps give some artificial
name to this PARM_DECL and make it DECL_NAMELESS.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (7 preceding siblings ...)
2010-12-17 8:55 ` jakub at gcc dot gnu.org
@ 2010-12-17 9:44 ` jakub at gcc dot gnu.org
2010-12-18 8:02 ` aoliva at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu.org @ 2010-12-17 9:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-17 09:44:03 UTC ---
Created attachment 22794
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22794
gcc46-pr46724-incremental.patch
Incremental patch for that.
BTW, the reason why a location list is used is because it is needed - it
doesn't cover the whole function, when inside of the abort call r2 might be
clobbered within the abort call. Therefore the range ends at .LVL1 - 1 instead
of .LVL1 (end of function).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (8 preceding siblings ...)
2010-12-17 9:44 ` jakub at gcc dot gnu.org
@ 2010-12-18 8:02 ` aoliva at gcc dot gnu.org
2010-12-18 8:05 ` aoliva at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-18 8:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #22792|0 |1
is obsolete| |
Attachment #22794|0 |1
is obsolete| |
--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-18 08:02:42 UTC ---
Created attachment 22806
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22806
Revised patch
This patch integrates Jakub's proposed changes and fixes a regression in
pr46815.C on x86_64-linux-gnu. A difference in DECL_BY_REFERENCE in the
RESULT_DECL required different handling in the DEBUG_VALUE_EXPR and in
var-tracking for proper handling. Regstrapping again after the changes...
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (9 preceding siblings ...)
2010-12-18 8:02 ` aoliva at gcc dot gnu.org
@ 2010-12-18 8:05 ` aoliva at gcc dot gnu.org
2010-12-22 3:49 ` aoliva at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-18 8:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #22806|0 |1
is obsolete| |
--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-18 08:05:20 UTC ---
Created attachment 22807
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22807
The actual revised patch
Doh, failed to refresh the patch file.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (10 preceding siblings ...)
2010-12-18 8:05 ` aoliva at gcc dot gnu.org
@ 2010-12-22 3:49 ` aoliva at gcc dot gnu.org
2010-12-22 3:56 ` aoliva at gcc dot gnu.org
2011-01-19 22:08 ` aoliva at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-22 3:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-22 03:49:06 UTC ---
Author: aoliva
Date: Wed Dec 22 03:49:00 2010
New Revision: 168160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168160
Log:
PR debug/46724
* function.c (assign_parms_augmented_arg_list): Name and mark
DECL of result address as NAMELESS rather than IGNORED.
(assign_parms): Set DECL_VALUE_EXPR for indirect result.
* tree.h (tree_decl_common::decl_flag_2): Document RESULT_DECL.
(DECL_HAS_VALUE_EXPR_P): Accept RESULT_DECL.
* dwarf2out.c (loc_list_from_tree) <RESULT_DECL>: Use
DECL_VALUE_EXPR.
* dbxout.c (dbxout_expand_expr) <RESULT_DECL>: Likewise.
* var-tracking.c (vt_add_function_parameter): New, split out of...
(vt_add_function_parameters): ... this. Handle incoming
pointer to hold result.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dbxout.c
trunk/gcc/dwarf2out.c
trunk/gcc/function.c
trunk/gcc/tree.h
trunk/gcc/var-tracking.c
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (11 preceding siblings ...)
2010-12-22 3:49 ` aoliva at gcc dot gnu.org
@ 2010-12-22 3:56 ` aoliva at gcc dot gnu.org
2011-01-19 22:08 ` aoliva at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2010-12-22 3:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
Alexandre Oliva <aoliva at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #12 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2010-12-22 03:55:54 UTC ---
Fixed
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug debug/46724] [4.6 Regression] Wrong debug info: Invalid variable location
2010-11-30 14:33 [Bug debug/46724] New: Wrong debug info: Invalid variable location krebbel at gcc dot gnu.org
` (12 preceding siblings ...)
2010-12-22 3:56 ` aoliva at gcc dot gnu.org
@ 2011-01-19 22:08 ` aoliva at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: aoliva at gcc dot gnu.org @ 2011-01-19 22:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46724
--- Comment #13 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-19 22:00:09 UTC ---
Author: aoliva
Date: Wed Jan 19 22:00:00 2011
New Revision: 169034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169034
Log:
PR debug/47079
PR debug/46724
* function.c (instantiate_expr): Instantiate incoming rtl of
implicit arguments, and recurse on VALUE_EXPRs.
(instantiate_decls): Instantiate rtl and VALUE_EXPR of result.
* var-tracking.c (adjust_mems): Reject virtual_incoming_args_rtx.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/var-tracking.c
^ permalink raw reply [flat|nested] 15+ messages in thread