[C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-06-28 Thread Sterling Augustine
The enclosed patch adds a fix for the pubnames anonymous namespaces contained within named namespaces, and adds an extensive test for the various pubnames. The bug is that when printing at verbosity level 1, and lang_decl_name sees a namespace decl in not in the global namespace, it prints the nam

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-07-01 Thread Gabriel Dos Reis
On Thu, Jun 28, 2012 at 12:50 PM, Sterling Augustine wrote: > The enclosed patch adds a fix for the pubnames anonymous namespaces contained > within named namespaces, and adds an extensive test for the various pubnames. > > The bug is that when printing at verbosity level 1, and lang_decl_name see

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-07-09 Thread Sterling Augustine
Committed as posted. Thanks. On Sun, Jul 1, 2012 at 7:33 AM, Gabriel Dos Reis wrote: > On Thu, Jun 28, 2012 at 12:50 PM, Sterling Augustine > wrote: >> The enclosed patch adds a fix for the pubnames anonymous namespaces contained >> within named namespaces, and adds an extensive test for the va

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-07-10 Thread Dominique Dhumieres
Hi Sterling, On x86_64-apple-darwin10 the test fails with FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler .section\t.debug_pubnames FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler "_GLOBAL__sub_I__ZN3one3c1vE0"+[ \t]+[#;]+[ \t]+external name FAIL: g++.dg/debug/dwarf2/pubnames-2.C

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-07-10 Thread Sterling Augustine
On Tue, Jul 10, 2012 at 6:51 AM, Dominique Dhumieres wrote: > Hi Sterling, > > On x86_64-apple-darwin10 the test fails with > > FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler > .section\t.debug_pubnames > FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler > "_GLOBAL__sub_I__ZN3one3c1vE

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-08-12 Thread Jack Howarth
On Sun, Jul 01, 2012 at 09:33:06AM -0500, Gabriel Dos Reis wrote: > On Thu, Jun 28, 2012 at 12:50 PM, Sterling Augustine > wrote: > > The enclosed patch adds a fix for the pubnames anonymous namespaces > > contained > > within named namespaces, and adds an extensive test for the various > > pubn

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-08-13 Thread Sterling Augustine
On Sun, Aug 12, 2012 at 12:46 PM, Jack Howarth wrote: > This patch introduces the regressions... > > FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler > .section\t.debug_pubnames > FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler > "_GLOBAL__sub_I__ZN3one3c1vE0"+[ \t]+[#;]+[ \t]+exte

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-08-13 Thread Sterling Augustine
On Sun, Aug 12, 2012 at 12:46 PM, Jack Howarth wrote: > On Sun, Jul 01, 2012 at 09:33:06AM -0500, Gabriel Dos Reis wrote: >> On Thu, Jun 28, 2012 at 12:50 PM, Sterling Augustine >> wrote: >> > The enclosed patch adds a fix for the pubnames anonymous namespaces >> > contained >> > within named na

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-08-13 Thread Mike Stump
On Aug 13, 2012, at 4:56 PM, Sterling Augustine wrote: > The enclosed patch adjusts the test so it will pass on darwin. The > issue was that it looked for some elf-specific assembly directives, > which it shouldn't. > > OK for mainline? Ok.

Re: [C++ Pubnames Patch] Anonymous namespaces enclosed in named namespaces. (issue6343052)

2012-08-14 Thread Sterling Augustine
On Mon, Aug 13, 2012 at 6:18 PM, Mike Stump wrote: > On Aug 13, 2012, at 4:56 PM, Sterling Augustine wrote: >> The enclosed patch adjusts the test so it will pass on darwin. The >> issue was that it looked for some elf-specific assembly directives, >> which it shouldn't. >> >> OK for mainline? > >