From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7334 invoked by alias); 16 Mar 2007 20:25:43 -0000 Received: (qmail 7191 invoked by uid 48); 16 Mar 2007 20:25:28 -0000 Date: Fri, 16 Mar 2007 20:25:00 -0000 Subject: [Bug debug/31230] New: debug information depends on gc parameters X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jsm28 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: 2007-03/txt/msg01584.txt.bz2 The following problem can cause bootstrap comparison failures in some circumstances (and was originally observed when bootstrapping with CFLAGS=-g BOOT_CFLAGS=-g). Consider the code from tree.c: /* See if the data pointed to by the type hash table is marked. We consider it marked if the type is marked or if a debug type number or symbol table entry has been made for the type. This reduces the amount of debugging output and eliminates that dependency of the debug output on the number of garbage collections. */ static int type_hash_marked_p (const void *p) { tree type = ((struct type_hash *) p)->type; return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type); } (TYPE_SYMTAB_POINTER, TYPE_SYMTAB_ADDRESS and TYPE_SYMTAB_DIE all name fields in the same union; the one applicable depends on the debug format in use.) The array type char[100] is generated, and handled for debug info purposes. Some time later, char[100] arises again. If there was no garbage collection inbetween, the same type is used and the debug info is shared. If however there was a garbage collection, the index type (the special integer type with range 0 to 99 used for TYPE_DOMAIN of the array type) gets garbage collected - while the array type is no doubt marked for debug info, the index type (which doesn't appear directly in debug info) isn't. Thus for the new char[100] type a new index type is generated, and so a new array type, and so extra debug info. I think there may also be other conditions required for the types to be garbage collected and to trigger this bug. I'll attach a .i file that shows it on i686-pc-linux-gnu if you compare the results of compiling with -g --param ggc-min-expand=0 --param ggc-min-heapsize=0 and -g --param ggc-min-expand=100 --param ggc-min-heapsize=131072, but it seems quite fragile. -- Summary: debug information depends on gc parameters Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230