From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29975 invoked by alias); 15 Oct 2008 18:30:17 -0000 Received: (qmail 29181 invoked by uid 48); 15 Oct 2008 18:28:56 -0000 Date: Wed, 15 Oct 2008 18:30:00 -0000 Message-ID: <20081015182856.29180.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 gcc dot gnu dot org" 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/msg01016.txt.bz2 ------- Comment #5 from jason at gcc dot gnu dot org 2008-10-15 18:28 ------- Contra Mark, this seems like a WONTFIX to me. g++ assumes that if a class has a vtable, if we're going to do anything with it we'll create an object of that type at some point, which will use the vtable, and so we'll get the debug info. This seems like a reasonable assumption to me; the only time it will be invalid is with trivial examples like this. No real code would try to cast to class2* when nothing in the program ever creates a class2. And if the user is doing something funny, there's the -femit-class-debug-always flag. In this case, we aren't omitting debug info for class2 because it's unused, we're omitting it because we know we'll emit it elsewhere. I think adding the -femit-class-debug-always flag to the testcase is the correct fix for the testsuite failure; changing the compiler to emit debug information more frequently would create a regression in debug info size. -- jason at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429