From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4884 invoked by alias); 29 Sep 2003 20:05:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4802 invoked from network); 29 Sep 2003 20:05:15 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 29 Sep 2003 20:05:15 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.10/8.12.10) with ESMTP id h8TITkOm018226; Mon, 29 Sep 2003 13:29:46 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h8TITkVd009817; Mon, 29 Sep 2003 13:29:46 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h8TITkqv009816; Mon, 29 Sep 2003 14:29:46 -0400 Date: Mon, 29 Sep 2003 20:19:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200309291829.h8TITkqv009816@duracef.shout.net> To: carlton@kealia.com Subject: Re: sunday project, gdb, 2003-09-26 Cc: gdb@sources.redhat.com X-SW-Source: 2003-09/txt/msg00383.txt.bz2 mec> . gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 mec> PASS -> KFAIL mec> This is a regression in gdb. The KFAIL is: mec> http://sources.redhat.com/gdb/bugs/826 mec> variables in C++ namespaces have to be enclosed in quotes mec> This happened with gcc v3 -gstabs+. dc> GCC 3.3, specifically: I don't see this with 3.2, where it's always dc> been a KFAIL. The debug info for stabs changed from 3.2 to 3.3, I dc> seem to recall. Same here. It didn't regress for me with gcc 3.2-7-rh because it was already KFAIL'ing with that. dc> Right: at first, I was wondering why you called this a regression, dc> given that it started out as a FAIL, but it really is the case that dc> the new output is worse. (Is there anything wrong with the old dc> output? It looks completely correct to me.) I think the old output is correct and it's just a matter of upgrading the test script to handle the many variations of 'ptype' output. Actually we could use some more infrastructure for doing that. Writing four to six 500-character regexp's for each ptype is very fragile. I'll make a "6.0 versus HEAD" regression report a little while after gdb 6.0 is released. Michael C