public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
@ 2011-07-06 23:28 Janis Johnson
  2011-07-07 16:14 ` Richard Earnshaw
  0 siblings, 1 reply; 5+ messages in thread
From: Janis Johnson @ 2011-07-06 23:28 UTC (permalink / raw)
  To: gcc-patches

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

For three tests in gcc.target/arm that don't depend on processor-specific
behavior, don't specify the -march option.  This makes dg-prune-output
for warnings about conflicts unnecessary, so remove it.

Two of these tests are for internal compiler errors that showed up with
particular values of -march.  I think it's fine to test them with normal
multilibs, some of which will use those -march values, and others of
which could trigger a closely-related ICE.

If there'a a desire to use specific options in a test, I'd prefer to see
it done in a copy of the test that is skipped for all multilibs but the
default.

OK for trunk, and for 4.6 after a few days?

[-- Attachment #2: gcc-20110706-3 --]
[-- Type: text/plain, Size: 1434 bytes --]

2011-07-06  Janis Johnson  <janisjo@codesourcery.com>

	* gcc.target/arm/pr41679.c: Remove -march options and unneeded
	dg-prune-output.
	* gcc.target/arm/pr46883.c: Likewise.
	* gcc.target/arm/xor-and.c: Likewise.

Index: gcc.target/arm/pr41679.c
===================================================================
--- gcc.target/arm/pr41679.c	(revision 175921)
+++ gcc.target/arm/pr41679.c	(working copy)
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-march=armv5te -g -O2" } */
-/* { dg-prune-output "switch .* conflicts with" } */
+/* { dg-options "-g -O2" } */
 
 extern int a;
 extern char b;
Index: gcc.target/arm/pr46883.c
===================================================================
--- gcc.target/arm/pr46883.c	(revision 175921)
+++ gcc.target/arm/pr46883.c	(working copy)
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O1 -march=armv5te" } */
-/* { dg-prune-output "switch .* conflicts with" } */
+/* { dg-options "-O1" } */
 
 void bar (unsigned char *q, unsigned short *data16s, int len)
 {
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)
 {

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
  2011-07-06 23:28 [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests Janis Johnson
@ 2011-07-07 16:14 ` Richard Earnshaw
  2011-07-07 16:44   ` Janis Johnson
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2011-07-07 16:14 UTC (permalink / raw)
  To: Janis Johnson; +Cc: gcc-patches

On 07/07/11 00:26, Janis Johnson wrote:
> For three tests in gcc.target/arm that don't depend on processor-specific
> behavior, don't specify the -march option.  This makes dg-prune-output
> for warnings about conflicts unnecessary, so remove it.
> 
> Two of these tests are for internal compiler errors that showed up with
> particular values of -march.  I think it's fine to test them with normal
> multilibs, some of which will use those -march values, and others of
> which could trigger a closely-related ICE.
> 
> If there'a a desire to use specific options in a test, I'd prefer to see
> it done in a copy of the test that is skipped for all multilibs but the
> default.
> 
> OK for trunk, and for 4.6 after a few days?
> 
> 
> gcc-20110706-3
> 
> 
> 2011-07-06  Janis Johnson  <janisjo@codesourcery.com>
> 
> 	* gcc.target/arm/pr41679.c: Remove -march options and unneeded
> 	dg-prune-output.
> 	* gcc.target/arm/pr46883.c: Likewise.
> 	* gcc.target/arm/xor-and.c: Likewise.
> 
> Index: gcc.target/arm/pr41679.c

I think this should just be moved to gcc.c-torture/compile.  There
doesn't seem to be anything processor-specific here.

> Index: gcc.target/arm/pr46883.c

Likewise.

> 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.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
  2011-07-07 16:14 ` Richard Earnshaw
@ 2011-07-07 16:44   ` Janis Johnson
  2011-07-07 16:51     ` Richard Earnshaw
  0 siblings, 1 reply; 5+ messages in thread
From: Janis Johnson @ 2011-07-07 16:44 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: gcc-patches

On 07/07/2011 09:14 AM, Richard Earnshaw wrote:
> On 07/07/11 00:26, Janis Johnson wrote:

>> Index: gcc.target/arm/pr41679.c
> 
> I think this should just be moved to gcc.c-torture/compile.  There
> doesn't seem to be anything processor-specific here.
> 
>> Index: gcc.target/arm/pr46883.c
> 
> Likewise.

OK, I'll do that.

>> 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.

Janis

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
  2011-07-07 16:44   ` Janis Johnson
@ 2011-07-07 16:51     ` Richard Earnshaw
  2011-07-07 17:57       ` Janis Johnson
  0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2011-07-07 16:51 UTC (permalink / raw)
  To: Janis Johnson; +Cc: gcc-patches

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests
  2011-07-07 16:51     ` Richard Earnshaw
@ 2011-07-07 17:57       ` Janis Johnson
  0 siblings, 0 replies; 5+ messages in thread
From: Janis Johnson @ 2011-07-07 17:57 UTC (permalink / raw)
  To: Richard Earnshaw; +Cc: gcc-patches

On 07/07/2011 09:48 AM, Richard Earnshaw wrote:
> 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.

The total number of tests is not the same.  A test that compiles and does
a scan is 2 tests when it is run but is only reported as 1 UNSUPPORTED.
We don't currently have a way to count things like dg-final or dg-error
as UNSUPPORTED if the entire test is skipped.

> 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.

I don't know.  I can leave it the way it is, always specifying -march
and ignoring warnings about conflicting options.  That doesn't guarantee,
though, that it will ever use the specified -march option because unless
there is a default multilib or one that doesn't use -march, the one in
the test will always be overridden by multilib options.

Janis

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-07-07 17:38 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-06 23:28 [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests Janis Johnson
2011-07-07 16:14 ` Richard Earnshaw
2011-07-07 16:44   ` Janis Johnson
2011-07-07 16:51     ` Richard Earnshaw
2011-07-07 17:57       ` Janis Johnson

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).