public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mike Stump <mikestump@comcast.net>
To: Janis Johnson <janisjo@codesourcery.com>
Cc: Richard Earnshaw <rearnsha@arm.com>,
	"Joseph S. Myers" <joseph@codesourcery.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [testsuite] skip ARM tests with conflicting options
Date: Wed, 08 Jun 2011 19:34:00 -0000	[thread overview]
Message-ID: <8CE2E40D-64A2-4A5D-9351-BFFEC5438424@comcast.net> (raw)
In-Reply-To: <4DEF953B.7050801@codesourcery.com>

On Jun 8, 2011, at 8:28 AM, Janis Johnson wrote:
> The big question is whether such a test should be run for all multilibs
> that might possibly pass the test, or only for default and for mulitlibs
> that provide the same options.

Here, reasonable people may disagree.  I suspect in the end, we'll have both solutions, and then individual testcases will make their own decision.  A collection of testcases will tend to follow the same convention...  So, for objective-c, we face the same sort of issue, and we do what we do, and that isn't necessarily going to match exactly what for example the gcc.arm does, nor I suspect are we going to change just because gcc.arm changes.  I think it makes sense to cache as much as possible and skip conflicts.  Taking off my testsuite maintainer hat, I think soft conflicts with defaults should mean we run it, and punch in the options we want.  If there is something that prohibits that from working (hard conflict), it should be skipped.  Feel free to ignore this, as I don't know that this is the best answer.

I'd like to think that dg-skip-if and dg-require-effective-target and general target selection is beefy enough to do everything we need it to, or can be made to.

  reply	other threads:[~2011-06-08 19:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-07 21:12 Janis Johnson
2011-06-07 21:20 ` Joseph S. Myers
2011-06-07 22:25   ` Janis Johnson
2011-06-07 23:37   ` Janis Johnson
2011-06-08  2:03     ` Mike Stump
2011-06-08  2:54       ` Janis Johnson
2011-06-08 11:47         ` Richard Earnshaw
2011-06-08 16:13           ` Janis Johnson
2011-06-08 19:34             ` Mike Stump [this message]
2011-06-08 20:51               ` Janis Johnson
2011-06-08 19:39           ` Mike Stump
2011-06-10  0:11           ` Janis Johnson
2011-06-10 10:12             ` Richard Earnshaw
2011-06-10 16:22               ` Janis Johnson

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=8CE2E40D-64A2-4A5D-9351-BFFEC5438424@comcast.net \
    --to=mikestump@comcast.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=janisjo@codesourcery.com \
    --cc=joseph@codesourcery.com \
    --cc=rearnsha@arm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).