This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/47858] [4.5/4.6/4.7 Regression] IPA-SRA decreases quality of debug info
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 3 Jun 2011 10:46:42 +0000
- Subject: [Bug debug/47858] [4.5/4.6/4.7 Regression] IPA-SRA decreases quality of debug info
- Auto-submitted: auto-generated
- References: <bug-47858-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #24416|0 |1
is obsolete| |
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-03 10:46:40 UTC ---
Created attachment 24422
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24422
gcc47-pr47858.patch
Updated patch, just added tree-sra.c bits for ipa-sra to add DEBUG x s=> y
and DEBUG z => D#N stmts as needed, and create VAR_DECL for the omitted
arguments. With this DW_OP_GNU_parameter_ref is generated both for all places
in #c0 and #c4 testcases where it should.
Thinking more about DW_OP_GNU_parameter_ref vs. typed DWARF stack, I think it
will need as optional parameter the base type die, because unlike
DW_OP_GNU_entry_value where the type is derived from the type of the inner
expression (e.g. regval_type vs. breg/reg and deref_type vs. deref{,_size}) the
DWARF consumer needs to know which type should be used for the parameter.
So, it could be DW_OP_GNU_parameter_ref <uleb128, data4> where the first
argument is either 0 (untyped) or base type DIE offset, and second argument is
DIE offset of the DW_TAG_formal_parameter.
Or, it could have no explicit type and the type would be taken from the caller
DW_TAG_GNU_call_site_parameter's DW_AT_GNU_call_site_value.
Preferences from debug consumer folks?
For the (still unimplemented) caller side representation in GIMPLE and RTL,
I forgot we don't need just list of DEBUG_EXPR_DECLs/DEBUG_EXPRs, we actually
need a list of pairs <PARM_DECL, DEBUG_EXPR_DECL/DEBUG_EXPR> and propagate that
list up to var-tracking.