Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Elizabeth Chastain <mec@shout.net>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] gdb.c++/method.exp: xfail for missing const
Date: Mon, 08 Apr 2002 15:24:00 -0000	[thread overview]
Message-ID: <200204082224.g38MOpt09754@duracef.shout.net> (raw)

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


             reply	other threads:[~2002-04-08 22:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-08 15:24 Michael Elizabeth Chastain [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-08 12:28 Michael Elizabeth Chastain
2002-04-08 14:07 ` Daniel Jacobowitz
2002-04-08 11:32 Michael Elizabeth Chastain
2002-04-08 11:46 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200204082224.g38MOpt09754@duracef.shout.net \
    --to=mec@shout.net \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox