From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25242 invoked by alias); 16 Jan 2003 14:20:10 -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 25224 invoked from network); 16 Jan 2003 14:20:07 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 16 Jan 2003 14:20:07 -0000 Received: from redhat.com (totem.toronto.redhat.com [172.16.14.242]) by touchme.toronto.redhat.com (Postfix) with ESMTP id D34AF800086; Thu, 16 Jan 2003 09:20:06 -0500 (EST) Message-ID: <3E26BF96.2030607@redhat.com> Date: Thu, 16 Jan 2003 14:20:00 -0000 From: Fernando Nasser Organization: Red Hat , Inc. - Toronto User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain Cc: ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] Remove all setup_xfail's from testsuite/gdb.mi/ References: <200301151744.h0FHi6O27664@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-01/txt/msg00597.txt.bz2 Michael Elizabeth Chastain wrote: > > I agree with Fernando that it's okay to tie every XFAIL to a gdb PR > and turn it into a KFAIL (at least, I think he is saying that). > Right. > Let's take a specific case. gdb.base/constvars.exp has a lot of > tests such as "const char * foo ; ptype foo". With gcc 2.95.3/stabs+, > the "ptype" prints "char * foo". This happens because gcc 2.95.3/stabs+ > does not put any const information in the stabs. This is probably never > going to get fixed in the gcc 2 series. > That is a true XFAIL, but it should be conditional to version 2 compilers and stabs, so that it does not show as XPASS everywhere else. > Now the real problem comes to light. 'K' and 'X' are really orthogonal. > 'K' means that we know about the problem, and 'X' means that it is > a problem in an external tool, and these two things are separate. > But we made them an either/or, so we have to choose. > > I'd rather have this become a KFAIL with reference to a gdb PR. Then > the gdb PR can say that this incorrect behavior happens, but it's not > gdb's fault. The gdb PR should refer to a gcc PR or other external PR. > And then we can't close the gdb PR until gcc revives gcc 2.X development > or gdb drop supports for gcc 2.X. > > We could add another PR state for these kind of PR's, or we could > just use the 'suspended' state. > The Dejagnu community will kill me if I come out with yet another type of failure ;-) The problem is that the international standard don't even recognize these extensions we've added (XFAIL and KFAIL), although I think they are really important and your weekely reports prove that. >>>From the gdb user's point of view, a bug is a bug. A gdb user can do > the same thing as the test suite and then file a PR: 'gdb fails to > print 'const' for const types'. > Yes, but we have little control over what we call XFAIL cases. But you have a good point that they deserve some user documentation as much as the KFAILs do. Please see my reply to Daniel's message. -- Fernando Nasser Red Hat - Toronto E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9