public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: Janis Johnson <janisjo@codesourcery.com>
Cc: Mike Stump <mikestump@comcast.net>,
	 "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 11:47:00 -0000	[thread overview]
Message-ID: <4DEF516C.7060703@arm.com> (raw)
In-Reply-To: <4DEEDAF0.6090100@codesourcery.com>

On 08/06/11 03:14, Janis Johnson wrote:
> On 06/07/2011 06:25 PM, Mike Stump wrote:
>> On Jun 7, 2011, at 4:24 PM, Janis Johnson wrote:
>>> On 06/07/2011 02:07 PM, Joseph S. Myers wrote:
>>>> On Tue, 7 Jun 2011, Janis Johnson wrote:
>>>>
>>>>> Several tests in gcc.target/arm use dg-options with -mcpu=xxxx, which
>>>>> causes compiler warnings or errors when the multilib flags include
>>>>> -march=yyyy.  This patch causes those tests to be skipped.  It also
>>>>> prevents gcc.target/arm/20090811-1.c from running with multilibs that
>>>>> would override -mcpu or -mfloat-abi options specified for the test.
>>>>
>>>> I think you should allow compatible -march options - for example, if 
>>>> dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all 
>>>> other -march options.
>>>>
>>> Is this one OK?
>>
>> Not sure if the arm people want to review this or would rather I review it...
>>
>> Let's give the arm folks a couple days to comment, if no objections, Ok.
>>
>> A point of warning, eventually, you'll discover that when a compiler defaults to the argument you want to skip, that you'll needs slightly more power to skip them.  darwin ran into this with things like -m64, and eventually had to do something like lp64.  configure options like --with-cpu=arm9 are the sort that can change the default.
> 
> Yes, I hope to hear from ARM people.
> 
> On ARM, the default from --with-cpu= is overridden by -march at
> compile so it's not a problem for this particular set of tests.
> As I said originally, this set is the tip of the iceberg and they
> get more difficult.
> 
> Janis
> 
> 


I'm worried by this whole approach of command-line checking.  It works,
just about, for testsuite variations set with target_list, but it won't
work with options used to configure the compiler (eg --with-mode=thumb,
or --with-cpu=...).  Perhaps a better approach would be a new dg- test
that built a trivial file with all the options and disabled the test if
that test failed for any reason.  Something like:

dg-target-compatible (target, <compile|link>, additional-opts)

The test is only performed if target matches the current target.

I'm not sure if this is something that can be easily cached (well, it
might be possible if you could index off additional-opts and the default
opts), so it might be that this test has to be re-run every time there
is a test that needs it.

R.


  reply	other threads:[~2011-06-08 10:40 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 [this message]
2011-06-08 16:13           ` Janis Johnson
2011-06-08 19:34             ` Mike Stump
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=4DEF516C.7060703@arm.com \
    --to=rearnsha@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=janisjo@codesourcery.com \
    --cc=joseph@codesourcery.com \
    --cc=mikestump@comcast.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).