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: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
Date: Thu, 07 Jul 2011 16:51:00 -0000	[thread overview]
Message-ID: <4E15E350.9070902@arm.com> (raw)
In-Reply-To: <4E15DF33.90500@codesourcery.com>

On 07/07/11 17:30, Janis Johnson wrote:
> On 07/07/2011 09:14 AM, Richard Earnshaw wrote:
>> On 07/07/11 00:26, Janis Johnson wrote:
>>> Index: gcc.target/arm/xor-and.c
>>> ===================================================================
>>> --- gcc.target/arm/xor-and.c	(revision 175921)
>>> +++ gcc.target/arm/xor-and.c	(working copy)
>>> @@ -1,6 +1,5 @@
>>>  /* { dg-do compile } */
>>> -/* { dg-options "-O -march=armv6" } */
>>> -/* { dg-prune-output "switch .* conflicts with" } */
>>> +/* { dg-options "-O" } */
>>>  
>>>  unsigned short foo (unsigned short x)
>>>  {
>>
>> The purpose of this test seems to be to ensure that when compiling for
>> v6 we don't get particular instructions.  Removing the -march flag means
>> we won't normally test this in the way intended (ie unless the multilibs
>> explicitly test v6).  This is one of those cases where I think the
>> intention really is to force one particular instruction set.
>>
>> R.
> 
> It passes everywhere, do you want to know when it stops passing for some
> other multilib, or just care about armv6?  If you only care about armv6
> then the test should be limited to run with the default multilib instead
> of having to muck around checking for incompatible options.
> 

We only care about v6 here, I think.  There aren't really any multilib
issues, since it's a compile-only test.  I don't mind not testing it for
non-default multilibs, but it should be marked as 'skipped' or recorded
in some other way, so that the total number of tests is the same for
each variant.

BTW, can the testsuite ever be run with no default multilib?  If so,
then I don't think we should always skip the test.

R.

  reply	other threads:[~2011-07-07 16:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06 23:28 Janis Johnson
2011-07-07 16:14 ` Richard Earnshaw
2011-07-07 16:44   ` Janis Johnson
2011-07-07 16:51     ` Richard Earnshaw [this message]
2011-07-07 17:57       ` 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=4E15E350.9070902@arm.com \
    --to=rearnsha@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=janisjo@codesourcery.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).