From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15175 invoked by alias); 16 Oct 2008 18:41:36 -0000 Received: (qmail 14696 invoked by alias); 16 Oct 2008 18:40:02 -0000 Date: Thu, 16 Oct 2008 18:41:00 -0000 Message-ID: <20081016184002.14695.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jason at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-10/txt/msg01119.txt.bz2 ------- Comment #10 from jason at redhat dot com 2008-10-16 18:40 ------- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always mark at codesourcery dot com wrote: > The library is provided to us in binary form and stripped, and if it > does have debug info it might not have come from GCC. But, if it's > declared in a header, we can still provide debug info. In which case we need to specify -femit-class-debug-always, yes. > OK, my statement was overly strong. I was thinking particularly of C++ > templates, where the vague linkage strategy makes for lots of copies, > both in the object files, and, because we don't use COMDAT, in the final > binaries. In that kind of C++ code, this optimization doesn't save a > significant percentage of space. I wouldn't expect it to make a big difference with heavily templated code, no. It seems to me that you're arguing that -femit-class-debug-always should go back to being on by default; its only effect is to control this exact optimization. But the documentation says -- This option should be used only with debuggers that are unable to handle the way GCC normally emits debugging information for classes because using this option will increase the size of debugging information by as much as a factor of two. -- Does anyone have some recent numbers? Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429