Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fernando Nasser <fnasser@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Andrew Cagney <ac131313@cygnus.com>,
	Michael Elizabeth Chastain <mec@shout.net>,
	gdb-patches@sources.redhat.com
Subject: Re: [rfa:testsuite} Overhaul sizeof.exp
Date: Wed, 20 Feb 2002 09:24:00 -0000	[thread overview]
Message-ID: <3C73DB96.3FF6DCE6@redhat.com> (raw)
In-Reply-To: <20020220115110.A14867@nevyn.them.org>

Daniel Jacobowitz wrote:
> 
> On Wed, Feb 20, 2002 at 11:15:44AM -0500, Fernando Nasser wrote:
> > Andrew Cagney wrote:
> > >
> > > The XFAIL policy is different to GDB.  GDB interprets XFAILs to mean not
> > > supported due to something outside of GDB's control.  Not this is a bug
> > > but we're not fixing it at present.
> > >
> >
> > Gdb follows the Dejagnu intended meaning for XFAILs.
> 
> Really?  I think you mean that GCC does.  From the DejaGNU manual:
> 
> `XFAIL'
>      A test failed, but it was expected to fail.  This result indicates
>      no change in a known bug.  If a test fails because the operating
>      system where the test runs lacks some facility required by the
>      test, the outcome is `UNSUPPORTED' instead.
> 
> XFAILS are intended to represent known bugs, and we should be using
> UNSUPPORTED more heavily.
> 

"lacks some facility required by the test" means something that the OS
or
run environment does not support and will never support because it is
just not the way things are done on that type of system.

We should _not_ be using UNSUPPORTED at large.


"This result indicates no change in a known bug."  This sentence is too
ambiguous.  I guess you can twist it in any way you want.

The GDB meaning for "A test failed, but it was expected to fail", for
many
years now, has been that there is a problem in the OS/runtime
environment
that will cause it to fail.  That is why it is normally marked as xfail
for some specific target triplet.

I guess the reasoning was that nobody normally "expects" something to
fail,
we expect something to work.  We only expect it to fail when there is
something
beyond our control that will cause it to fail and that we hope will be
fixed 
(and things suddenly become XPASSes).


Anyway, who has the right interpretation or not is irrelevant.  We do
have
two distinct situations and it would be nice to be able to handle them
accordingly.



-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


  reply	other threads:[~2002-02-20 17:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-19 20:57 Michael Elizabeth Chastain
2002-02-20  6:57 ` Andrew Cagney
2002-02-20  7:21   ` Andrew Cagney
2002-02-20  8:19     ` Fernando Nasser
2002-02-20 17:57       ` Andrew Cagney
2002-02-20  8:16   ` Fernando Nasser
2002-02-20  8:51     ` Daniel Jacobowitz
2002-02-20  9:24       ` Fernando Nasser [this message]
2002-02-21 14:04       ` Jim Blandy
2002-02-21 14:23         ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2002-02-20 10:24 Michael Elizabeth Chastain
2002-02-20 11:48 ` Fernando Nasser
2002-02-20  9:49 Michael Elizabeth Chastain
2002-02-20 10:06 ` Fernando Nasser
2002-02-20 10:12   ` Daniel Jacobowitz
2002-02-20 10:07 ` Daniel Jacobowitz
2002-02-20 10:18   ` Fernando Nasser
2002-02-20 10:07 ` Richard Earnshaw
2002-02-20  9:17 Michael Elizabeth Chastain
2002-02-20  9:42 ` Fernando Nasser
2002-02-20 10:20 ` Andrew Cagney
2002-02-20  8:59 Michael Elizabeth Chastain
2002-02-19 20:43 Michael Elizabeth Chastain
2002-02-21 14:03 ` Jim Blandy
2002-02-19 15:46 Michael Elizabeth Chastain
2002-02-19 18:19 ` Andrew Cagney
2002-02-19 15:17 Andrew Cagney

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=3C73DB96.3FF6DCE6@redhat.com \
    --to=fnasser@redhat.com \
    --cc=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=mec@shout.net \
    /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