On Oct 5, 2012, at 11:34 AM, <paul_kon...@dell.com> <paul_kon...@dell.com> wrote:
> > On Oct 5, 2012, at 4:16 AM, Jakub Jelinek wrote: > >> On Thu, Oct 04, 2012 at 05:26:11PM -0700, Cary Coutant wrote: >>>> Index: gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C >>>> =================================================================== >>>> --- gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (revision 192048) >>>> +++ gcc/testsuite/g++.dg/debug/dwarf2/localclass1.C (working copy) >>>> @@ -59,11 +59,11 @@ >>>> // { dg-final { scan-assembler "foo\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler "staticfn1\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler "staticfn2\[^\n\r\]*DW_AT_name" } } >>>> -// { dg-final { scan-assembler-not "staticfn3\[^\n\r\]*DW_AT_name" } } >>>> -// { dg-final { scan-assembler-not "staticfn4\[^\n\r\]*DW_AT_name" } } >>>> +// { dg-final { scan-assembler "staticfn3\[^\n\r\]*DW_AT_name" } } >>>> +// { dg-final { scan-assembler "staticfn4\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler-not "staticfn5\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler-not "staticfn6\[^\n\r\]*DW_AT_name" } } >>>> -// { dg-final { scan-assembler-not "method1\[^\n\r\]*DW_AT_name" } } >>>> +// { dg-final { scan-assembler "method1\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler "arg1\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler "arg2\[^\n\r\]*DW_AT_name" } } >>>> // { dg-final { scan-assembler "arg3\[^\n\r\]*DW_AT_name" } } >>> >>> The fact that these two tests were specifically checking for the >>> absence of staticfn3 and staticfn4 leads me to believe that the >>> current behavior is deliberate. Jakub, that change was yours (it dates >>> back to November 2008). Are you OK with Paul's change? >> >> Yes, thought it would be interesting to get some .debug_info size growth >> numbers for a few projects (say libstdc++.so and some larger C++ codebase >> (some KDE core library, or OO.o) without/with the patch, to see how much >> does it bring with it (I'm not that much worried about the DW_TAG_subprogram >> added itself, but about about types it will additionally bring in). >> We have dwz and likely would get most of the growth back due to redundancy >> removal though. >> >> Jakub > > I did a quick test on a large application of ours where this issue was > causing trouble. Without the patch, it generates 115 MB of debug data; with > the patch, that grows to 120 MB. So given the comments, is this patch now ok to commit? Thanks, paul