From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5161 invoked by alias); 2 Jul 2003 17:07:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5142 invoked from network); 2 Jul 2003 17:07:54 -0000 Received: from unknown (HELO hawaii.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 2 Jul 2003 17:07:54 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 0284FBFE3; Wed, 2 Jul 2003 10:07:53 -0700 (PDT) To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/testsuite] gdb.c++/classes.exp: add another ptype pattern References: <200307021649.h62GnKLW026005@duracef.shout.net> From: David Carlton Date: Wed, 02 Jul 2003 17:07:00 -0000 In-Reply-To: <200307021649.h62GnKLW026005@duracef.shout.net> (Michael Elizabeth Chastain's message of "Wed, 2 Jul 2003 12:49:20 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00038.txt.bz2 On Wed, 2 Jul 2003 12:49:20 -0400, Michael Elizabeth Chastain said: > The big stab for ClassWithEnum is the same, but the stab for the > nested enum changed from 'PrivEnum' to 'ClassWithEnum::PrivEnum'. > The hypothetical case has came to life. Argh! > Is it good for us that gcc 3.3 and later versions output > 'ClassWithEnum::PrivEnum'? Or should I file a bug report against > gcc and ask them to put it back to just plain 'PrivEnum'? It might be a good idea as part of a larger change (to the names of all nested classes). It's probably not a great idea if the change only involves enums nested with classes, though others might disagree with me on that. What certainly isn't a good idea is that it's changed and nobody has bothered to discuss this with us. Maybe a good course of action would be to post to gcc@ asking about it. > So it's hard to write the test case at this point. But it's done the > job of alerting us to a difference in gcc output. Right. David Carlton carlton@kealia.com