Created attachment 17469 [details]
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?

Thanks although there is still excessive DW_AT_name:
 <3><422>: 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.

Created attachment 17471 [details]
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.

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=17469&action=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.

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."

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.

Created attachment 17472 [details]
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 ();
  bar<0> ();
  bar<6> ();
}

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.

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=17472&action=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 ?

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.

ICE: Comment 7 patch (applied together with the Comment 3 patch) on:
--------------------------------------------------------------------------------
namespace A
{
  class B
  {
  };
};

extern void g ();

void
f ()
{
  using A::B;

  g ();
}
--------------------------------------------------------------------------------
1.C: In function ‘void f()’:
1.C:16: internal compiler error: in force_decl_die, at dwarf2out.c:15092
g++ (GCC) 4.4.0 20090316 (experimental)

Created attachment 17477 [details]
gcc44-local-imported-decl.patch

Yeah, I know, found that out already during my regtest.  Here is what I'm bootstrapping/regtesting instead.

(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.

Subject: Bug 39471

Author: jakub
Date: Tue Mar 17 17:49:28 2009
New Revision: 144911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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

Fixed.