[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-17 07:46 --- Created an attachment (id=17471) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17471action=view) gcc44-pr39471.patch So this patch instead? C++ will never need non-NULL DECL_NAME on IMPORTED_DECL, as it doesn't have the ability to rename imports like Fortran does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #4 from dodji at gcc dot gnu dot org 2009-03-17 07:54 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : --- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 --- Created an attachment (id=17469) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469action=view) gcc44-pr39471.patch Untested patch. Dodji, any reason why you started emitting DW_TAG_imported_declaration for this instead of DW_TAG_imported_module? I think this was just a confusion on my part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #5 from dodji at gcc dot gnu dot org 2009-03-17 07:59 ---
Subject: Re: DW_TAG_imported_module should be used (not
DW_TAG_imported_declaration)
jakub at gcc dot gnu dot org a écrit :
So this patch instead? C++ will never need non-NULL DECL_NAME on
IMPORTED_DECL,
as it doesn't have the ability to rename imports like Fortran does.
Hmmh, I think the non null name there is useful for namespace aliases in
C++, e.g.
namespace A {
int foo;
}
void
f ()
{
namespace B = A;
}
That namespace alias will be represented by a
DW_TAG_imported_declaration which DW_AT_name set to B and which
DW_AT_import is set to a reference to namespace A.
FWIW, the DWARF3 spec says at 3.2.3:
A C++ namespace alias may be represented by an imported declaration
entry with a name attribute whose value is a null-terminated string
containing the alias name as it appears in the source program and an
import attribute whose value is a reference to the applicable original
namespace or namespace extension entry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #6 from dodji at gcc dot gnu dot org 2009-03-17 08:08 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) dodji at redhat dot com a écrit : Hmmh, I think the non null name there is useful for namespace aliases in C++ Ah, no. We won't be going through the USING_STMT code path in case of namespace aliases, sorry. My last comment was irrelevant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 ---
Created an attachment (id=17472)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472action=view)
gcc44-local-imported-decl.patch
Incremental patch to emit DW_TAG_imported_declaration DIEs (other than
namespace aliases) in the right lexical blocks.
Possible testcase for gdb:
namespace A
{
int i = 1;
int j = 2;
}
namespace B
{
int k = 3;
}
int k = 13;
void
foo ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
}
template int N
void
bar ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
}
int
main ()
{
foo ();
bar0 ();
bar6 ();
}
Concerning:
We won't be going through the USING_STMT code path in case of We won't be
going through the USING_STMT code path in case of namespace aliases, sorry. My
last comment was irrelevant.
we really should be going through USING_STMT or something similar for namespace
aliases as well, see PR37890. Given that namespace aliases are just emitted
using gen_namespace_die, perhaps just adding the NAMESPACE_DECL to BLOCK_VARS
would be sufficient.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-03-17 10:05 --- I no longer see any DWARF problem there but Archer C++ still does not work with g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #8 from dodji at gcc dot gnu dot org 2009-03-17 10:02 --- Subject: Re: DW_TAG_imported_module should be used (not DW_TAG_imported_declaration) jakub at gcc dot gnu dot org a écrit : --- Comment #7 from jakub at gcc dot gnu dot org 2009-03-17 08:52 --- Created an attachment (id=17472) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17472action=view) gcc44-local-imported-decl.patch Incremental patch to emit DW_TAG_imported_declaration DIEs (other than namespace aliases) in the right lexical blocks. I am wondering what happens when cp_emit_debug_info_for_using is called for a using declaration that appears at global scope. Once we are in the USING_STMT case of cp_gimplify_expr, will there be an enclosing GIMPLE_BIND for the USING_STMT generated for the global using declaration ? For the record, cp_parser_using_declaration calls either do_local_using_decl or do_toplevel_using_decl, depending on if we are at local or global scope. Both do_local_using_decl and do_toplevel_using_decl end up calling cp_parser_using_declaration. Concerning: We won't be going through the USING_STMT code path in case of We won't be going through the USING_STMT code path in case of namespace aliases, sorry. My last comment was irrelevant. we really should be going through USING_STMT or something similar for namespace aliases as well, see PR37890. Given that namespace aliases are just emitted using gen_namespace_die, perhaps just adding the NAMESPACE_DECL to BLOCK_VARS Yeah I should try something like that in cp_gimplify_expr whenever we are handed BIND_EXPR. In that case, I can wall the BIND_EXPR_VARS of the of the BIND_EXPR and add any NAMESPACE_DECL to the BLOCK_VARS of the matching block. Would that make sense ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-17 12:28 --- Created an attachment (id=17477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17477action=view) gcc44-local-imported-decl.patch Yeah, I know, found that out already during my regtest. Here is what I'm bootstrapping/regtesting instead. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #17472|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #12 from swagiaal at redhat dot com 2009-03-17 15:17 --- (In reply to comment #9) I no longer see any DWARF problem there but Archer C++ still does not work with g++-4.4. Assuming an Archer bug due to the new DW_TAG_lexical_block block. Yes there are a couple I am looking at them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-17 17:49 --- Subject: Bug 39471 Author: jakub Date: Tue Mar 17 17:49:28 2009 New Revision: 144911 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144911 Log: PR debug/39471 * dwarf2out.c (dwarf2out_imported_module_or_decl_1): Emit DW_TAG_imported_module even if decl is IMPORTED_DECL with NAMESPACE_DECL in its DECL_INITIAL. * cp-gimplify.c (cp_gimplify_expr): Don't set DECL_NAME on IMPORTED_DECL. * g++.dg/debug/dwarf2/imported-module-2.C: Expect DW_TAG_imported_module, not just any DW_TAG_imported prefixed tag. * g++.dg/debug/dwarf2/imported-module-3.C: Likewise. * g++.dg/debug/dwarf2/imported-module-4.C: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #14 from jakub at gcc dot gnu dot org 2009-03-17 17:56 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-16 20:55 ---
Created an attachment (id=17469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17469action=view)
gcc44-pr39471.patch
Untested patch. Dodji, any reason why you started emitting
DW_TAG_imported_declaration for this instead of DW_TAG_imported_module?
Also, looking at the http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410#c6
comment, I'm wondering about the C++ doesn't allow that usage part in the
comment. Isn't:
namespace A
{
int i = 1;
int j = 2;
}
namespace B
{
int k = 3;
}
int k = 13;
int
main ()
{
using namespace A;
i++;
j++;
k++;
{
using B::k;
k++;
}
return 0;
}
a testcase which needs IMPORTED_DECL with non-NAMESPACE_DECL
IMPORTED_DECL_ASSOCIATED_DECL?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
[Bug debug/39471] DW_TAG_imported_module should be used (not DW_TAG_imported_declaration)
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-03-16 21:37 --- Thanks although there is still excessive DW_AT_name: 3422: Abbrev Number: 12 (DW_TAG_imported_module) 425 DW_AT_name: A 427 DW_AT_import : 0x113 [Abbrev Number: 2 (DW_TAG_namespace)] DW_AT_name looks as undefined for me for DW_TAG_imported_module and it certainly breaks the current Archer C++ implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39471
