From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30934 invoked by alias); 8 Apr 2002 22:24:58 -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 30927 invoked from network); 8 Apr 2002 22:24:57 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by sources.redhat.com with SMTP; 8 Apr 2002 22:24:57 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id g38MOpt09754; Mon, 8 Apr 2002 17:24:51 -0500 Date: Mon, 08 Apr 2002 15:24:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200204082224.g38MOpt09754@duracef.shout.net> To: drow@mvista.com Subject: Re: [PATCH] gdb.c++/method.exp: xfail for missing const Cc: gdb-patches@sources.redhat.com X-SW-Source: 2002-04/txt/msg00323.txt.bz2 Daniel Jacobowitz writes: danj> What I meant is that, in the hypothetical situation where we danj> const-qualified things accidentally, if we were using GCC 2.95/stabs (a danj> combination which "we, the testsuite" know can not say "const"!) danj> printing out const would be quite surprising. Well, there are so few XPASS's, that I am definitely adding XPASS to my attention reports. I'm also adding XFAIL's. In fact everything except a PASS is now in the attention report. The difference reports already pick up any XFAIL -> XPASS transitions. mec> I would like that too. But how can the test script determine the gcc mec> version? I don't see a way to do this in gdb/lib.exp. danj> It's not there. I can add it trivially, if you want. The major danj> version is there already; it's [ $gcc_compiled > 2 ]. We could just danj> set gcc_compiler_minor if necessary. They're __GNUC__ and danj> __GNUC_MINOR__. At this point I want to get the darn thing finished so that I can spend some time on local.exp and templates.exp, which are also very gnarly and have a lot of bit rot. So since the feature is not there, I'm going to go ahead with 'setup_xfail_format "stabs"' and not worry about this. It would still be useful to import the gcc version number into the dejagnu context, because we are going to have this "const" issue for another 2-3 years. Michael C