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.
next prev parent 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).