Re: [testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux

[Janis Johnson]

On 10/09/2012 07:39 AM, Richard Earnshaw wrote:
> On 27/09/12 01:02, Janis Johnson wrote:
>> Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux
>> targets, as described in PR54732.  This patch adds an XFAIL.
>>
>> Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.
>>
>> Janis
>>
>>
>> gcc-20120926-5
>>
>>
>> 2012-09-26  Janis Johnson  
>>
>>  * gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.
>>
>> Index: gcc.target/arm/div64-unwinding.c
>> ===
>> --- gcc.target/arm/div64-unwinding.c (revision 191765)
>> +++ gcc.target/arm/div64-unwinding.c (working copy)
>> @@ -1,6 +1,7 @@
>>   /* Performing a 64-bit division should not pull in the unwinder.  */
>>
>> -/* { dg-do run } */
>> +/* The test is expected to fail for GNU/Linux; see PR54723.  */
>> +/* { dg-do run { xfail *-*-linux* } } */
>>   /* { dg-options "-O0" } */
>>
>>   #include 
>>
> 
> I don't like this.  To me, XFAIL means "there's a bug here, but we're 
> not too worried about it".  The behaviour on linux targets is correct, 
> so this test should either PASS or be skipped.

Richard,

The impression I got from Julian is "there's a bug here, but we're not
too worried about it".  If you think it should be skipped instead then
I'll gladly change the test.

Janis

Re: [PATCH] Adjust target for vect/pr48765.c

[Janis Johnson]

On 10/12/2012 08:05 AM, Joe Seymour wrote:
> I'm observing vect/pr48765.c fail for non 64-bit PowerPC targets:
> 
>> gcc/testsuite/gcc.dg/vect/pr48765.c:1:0: error: -m64 not supported in this
> configuration
> 
> This patch restricts the test to 64-bit PowerPC targets. I don't have commit
> access, so if this OK perhaps someone could commit it for me?
> 
> Thanks,
> 
> 2012-10-12  Joe Seymour  
> 
>   * gcc.dg/vect/pr48765.c: Restrict to 64-bit PowerPC targets.
> 
> Index: gcc/testsuite/gcc.dg/vect/pr48765.c
> ===
> --- gcc/testsuite/gcc.dg/vect/pr48765.c (revision 192402)
> +++ gcc/testsuite/gcc.dg/vect/pr48765.c (working copy)
> @@ -1,4 +1,4 @@
> -/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-do compile { target powerpc64 } } */
>  /* { dg-options "-m64 -O3 -mcpu=power6" } */
> 
>  enum reg_class
> 

No, the test should not add -m64, and -mcpu=power6 might conflict
with multilib options.  I proposed a different fix for this test in
 and then
didn't follow up on it.

I've copied Ira who added the test to see what she thinks of my
proposed change, and David as the Power maintainer.

Janis

Re: [testsuite] Prune irrelevant warning from pr53060.c

[Janis Johnson]

On 10/12/2012 11:31 AM, Joe Seymour wrote:
> The pr53060.c test for excess errors fails on some PowerPC targets with an
> unexpected warning: "GCC vector returned by reference: non-standard ABI
> extension with no compatibility guarantee"
> 
> This patch prunes the irrelevant warning as in pr34856.c. I don't have commit
> access, so perhaps someone could commit this if it's OK?
> 
> Thanks,
> 
> 2012-10-12  Joe Seymour  
> 
>   * gcc.dg/pr53060.c: Prune irrelevant warning.
> 
> Index: gcc/testsuite/gcc.dg/pr53060.c
> ===
> --- gcc/testsuite/gcc.dg/pr53060.c (revision 192269)
> +++ gcc/testsuite/gcc.dg/pr53060.c (working copy)
> @@ -22,3 +22,6 @@ int main()
>if (i[0] != 3) abort();
>return 0;
>  }
> +
> +/* Ignore a warning that is irrelevant to the purpose of this test.  */
> +/* { dg-prune-output ".*GCC vector returned by reference.*" } */

OK.  I've checked it in.

Janis

Re: [testsuite] gcc.target/arm: skip 5 tests for flag conflicts

[Janis Johnson]

On 10/10/2012 03:43 AM, Richard Earnshaw wrote:
> On 21/09/12 03:51, Janis Johnson wrote:
>> This patch adds test directives to skip 5 tests in gcc.target/arm if the
>> flags specified for the test would be overridden by or conflict with
>> flags used for all tests, such as multilib flags.
>>
>> Tested on arm-none-eabi with a variety of test flags.  I'll wait a day
>> or two before checking it in to give ARM experts a chance to comment.
>> I plan to backport to the 4.7 branch soon after it's in trunk.
>>
>> Janis
>>
>>
>> gcc-20120920-1
>>
>>
>> 2012-09-20  Janis Johnson  
>>
>>  * gcc.target/arm/pr40887.c: Avoid conflicting flags.
>>  * gcc.target/arm/pr51835.c: Likewise.
>>  * gcc.target/arm/pr51915.c: Likewise.
>>  * gcc.target/arm/pr52006.c: Likewise.
>>  * gcc.target/arm/pr53187.c: Likewise.
>>
>> Index: gcc.target/arm/pr40887.c
>> ===
>> --- gcc.target/arm/pr40887.c (revision 191502)
>> +++ gcc.target/arm/pr40887.c (working copy)
>> @@ -1,3 +1,4 @@
>> +/* { dg-skip-if " do not override -march" { *-*-* } { "-march=*" } { 
>> "-march=armv5te" } } */
>>   /* { dg-options "-O2 -march=armv5te" }  */
>>   /* { dg-final { scan-assembler "blx" } } */
>>
> 
> It looks like this test should be run on ARMv5TE or later, so doesn't 
> skipping this is weakening our testing?
> 
> As a secondary issue, -mcpu will override the -march setting quietly so 
> we could end up with testsuite failures if the compiler was being tested 
> with a -mcpu= flag.
> 
> 
>> Index: gcc.target/arm/pr51835.c
>> ===
>> --- gcc.target/arm/pr51835.c (revision 191502)
>> +++ gcc.target/arm/pr51835.c (working copy)
>> @@ -1,6 +1,8 @@
>>   /* { dg-do compile } */
>> +/* { dg-require-effective-target arm_thumb2_ok } */
>> +/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
>> { "-mfloat-abi=hard" } } */
>> +/* { dg-skip-if "do not override -mfpu" { *-*-* } { "-mfpu=*" } { 
>> "-mfpu=fpv4-sp-d16" } } */
>>   /* { dg-options "-O2 -mfloat-abi=hard -mfpu=fpv4-sp-d16" }  */
>> -/* { dg-require-effective-target arm_thumb2_ok } */
>>
> 
> Similarly, doesn't this weaken our test coverage?
> 
> 
>>   int func1 (double d)
>>   {
>> Index: gcc.target/arm/pr51915.c
>> ===
>> --- gcc.target/arm/pr51915.c (revision 191502)
>> +++ gcc.target/arm/pr51915.c (working copy)
>> @@ -1,5 +1,7 @@
>>   /* PR target/51915 */
>>   /* { dg-do compile } */
>> +/* { dg-skip-if "do not override -march" { *-*-* } { "-march=*" } { 
>> "-march=armv7-a" } } */
>> +/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
>> { "-mfloat-abi=hard" } } */
>>   /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
>>
>>   struct S { int s1; void *s2; };
>> Index: gcc.target/arm/pr52006.c
>> ===
>> --- gcc.target/arm/pr52006.c (revision 191502)
>> +++ gcc.target/arm/pr52006.c (working copy)
>> @@ -1,5 +1,7 @@
>>   /* PR target/52006 */
>>   /* { dg-do compile } */
>> +/* { dg-skip-if "do not override -march=" { *-*-* } { "-march=*" } { 
>> "-march=armv7-a" } } */
>> +/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } 
>> { "-mfloat-abi=hard" } } */
>>   /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2 -fPIC" } */
>>
>>   unsigned long a;
>> Index: gcc.target/arm/pr53187.c
>> ===
>> --- gcc.target/arm/pr53187.c (revision 191502)
>> +++ gcc.target/arm/pr53187.c (working copy)
>> @@ -1,5 +1,6 @@
>>   /* PR target/53187 */
>>   /* { dg-do compile } */
>> +/* { dg-skip-if "do not override -march" { *-*-* } { "-march=*" } { 
>> "-march=armv7-a" } } */
>>   /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
>>
>>   void bar (int);
>>
> 
> And the same for the rest.
> 
> Remind me again, why dg-options are on the command line before the 
> multilib options.
> 
> R.

Ric

Re: [PATCH, ARM] Fix PR44557 (Thumb-1 ICE)

[Janis Johnson]

On 10/19/2012 11:41 PM, Ramana Radhakrishnan wrote:
> On Tue, Oct 16, 2012 at 10:25 AM, Chung-Lin Tang
>  wrote:
>> On 12/9/27 6:25 AM, Janis Johnson wrote:
>>> On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
>>>
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer 
>>> -fno-forward-propagate" }  */
>>> +/* { dg-require-effective-target arm_thumb1_ok } */
>>>
>>> This test will fail to compile for test flags that conflict with
>>> the -march option, and the specified -march option might be
>>> overridden with similar options from other test flags.  The problem
>>> might have also been seen for other -march options.  I recommend
>>> leaving it off and omitting the dg-require so the test can be run
>>> for more multilibs.
>>
>> I'm not sure, as the intent is to test a Thumb-1 case here. If the
>> maintainers think we should adjust the testcase, I'm of course fine with it.
> 
> I think this is OK but you need to prune out the conflict warnings to
> reduce annoyance for folks doing multilib testing and it does look
> like more than one group.
> 
> Longer term I wonder if we should reorganise gcc.target/arm and indeed
> gcc.target/aarch64 . Janis, do you have any other ideas ?
> 
> * to contain a torture script that goes through all combinations of
> architectures and fpus' / arm / thumb for all the tests.
> * another sub-level directory for such directed tests where multilib
> options aren't applied which are essentially from regressions.
> 
> However I don't know of an easy way by which we can ignore said
> multilib flags ?
> 
> Ramana

Multilib flags are added deep in DejaGnu, and we would need to have a
local copy of a large procedure in order to do that.

Do enough people run a default multilib that we could use a torture
script only for a multilib with no flags?

Janis

[testsuite patch] add code to arm_thumbX_ok to exercise ABI

[Janis Johnson]

Running an arm-none-eabi test that adds "-mthumb" for a multilib that
uses "-march=armv5te -mfloat-abi=hard" works fine if the test doesn't
have any calls, but if it does then the effective-target checks for
arm_thumb1_ok and arm_thumb2_ok pass but the test's compile step fails
with "sorry, unimplemented: Thumb-1 hard-float VFP ABI".

This patch adds code to those effective-target checks to exercise
argument handling and causes them to fail for the multilib flags
listed above.  Tested by running gcc.target/arm tests with a variety
of multilib flags.  OK for mainline and the 4.9 branch?

Janis
2014-08-07  Janis Johnson  

* lib/target-supports.exp (check_effective_target_arm_thumb1_ok,
check_effective_target_arm_thumb2_ok): Test with code that passes
an argument and returns a result.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 213683)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -2761,6 +2761,7 @@
#if !defined(__arm__) || !defined(__thumb__) || defined(__thumb2__)
#error FOO
#endif
+   int foo (int i) { return i; }
 } "-mthumb"]
 }
 
@@ -2772,6 +2773,7 @@
#if !defined(__thumb2__)
#error FOO
#endif
+   int foo (int i) { return i; }
 } "-mthumb"]
 }
 

[testsuite patch] check before using -mthumb in 5 arm tests

[Janis Johnson]

Five tests in gcc.target/arm add -mthumb without first checking that the
option is compatible with the current multilib flags.  This patch fixes
that by skipping each test if neither arm_thumb1_ok or arm_thumb2_ok is
true.  Tested by running gcc.target/arm tests with a variety of multilib
flags, some of which now skip these tests instead of failing to compile.
OK for mainline and the 4.9 branch?

Janis
2013-08-07  Janis Johnson  

* gcc.target/arm/frame-pointer-1.c: Skip if Thumb is not supported.
* gcc.target/arm/pr56184.C: Likewise.
* gcc.target/arm/pr59896.c: Likewise.
* gcc.target/arm/stack-red-zone.c: Likewise.
* gcc.target/arm/thumb-find-work-register.c: Likewise.

Index: gcc/testsuite/gcc.target/arm/frame-pointer-1.c
===
--- gcc/testsuite/gcc.target/arm/frame-pointer-1.c  (revision 213683)
+++ gcc/testsuite/gcc.target/arm/frame-pointer-1.c  (working copy)
@@ -1,6 +1,7 @@
 /* Check local register variables using a register conventionally 
used as the frame pointer aren't clobbered under high register pressure.  */
 /* { dg-do run } */
+/* { dg-skip-if "incompatible options" { ! { arm_thumb1_ok || arm_thumb2_ok } 
} { "*" } { "" } } */
 /* { dg-options "-Os -mthumb -fomit-frame-pointer" } */
 
 #include 
Index: gcc/testsuite/gcc.target/arm/pr56184.C
===
--- gcc/testsuite/gcc.target/arm/pr56184.C  (revision 213683)
+++ gcc/testsuite/gcc.target/arm/pr56184.C  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { ! { arm_thumb1_ok || arm_thumb2_ok } 
} { "*" } { "" } } */
 /* { dg-options "-fno-short-enums -O2 -mthumb -march=armv7-a -mfpu=neon 
-mfloat-abi=softfp -mtune=cortex-a9 -fno-section-anchors" } */
 
 typedef unsigned int size_t;
Index: gcc/testsuite/gcc.target/arm/pr59896.c
===
--- gcc/testsuite/gcc.target/arm/pr59896.c  (revision 213683)
+++ gcc/testsuite/gcc.target/arm/pr59896.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { ! { arm_thumb1_ok || arm_thumb2_ok } 
} { "*" } { "" } } */
 /* { dg-options "-mthumb -O2" } */
 
 typedef unsigned int size_t;
Index: gcc/testsuite/gcc.target/arm/stack-red-zone.c
===
--- gcc/testsuite/gcc.target/arm/stack-red-zone.c   (revision 213683)
+++ gcc/testsuite/gcc.target/arm/stack-red-zone.c   (working copy)
@@ -1,4 +1,5 @@
 /* No stack red zone.  PR38644.  */
+/* { dg-skip-if "incompatible options" { ! { arm_thumb1_ok || arm_thumb2_ok } 
} { "*" } { "" } } */
 /* { dg-options "-mthumb -O2" } */
 /* { dg-final { scan-assembler "ldrb\[^\n\]*\\n\[\t \]*add\[\t \]*sp" } } */
 
Index: gcc/testsuite/gcc.target/arm/thumb-find-work-register.c
===
--- gcc/testsuite/gcc.target/arm/thumb-find-work-register.c (revision 
213683)
+++ gcc/testsuite/gcc.target/arm/thumb-find-work-register.c (working copy)
@@ -1,5 +1,6 @@
 /* Wrong method to get number of arg reg will cause argument corruption.  */
 /* { dg-do run } */
+/* { dg-skip-if "incompatible options" { ! { arm_thumb1_ok || arm_thumb2_ok } 
} { "*" } { "" } } */
 /* { dg-require-effective-target arm_eabi } */
 /* { dg-options "-mthumb -O1" } */
 

[testsuite patch] fix ARM tests with options that conflict with thumb1

[Janis Johnson]

Two tests in gcc.target/arm add options that conflict with thumb1
multilib flags; skip them.  Tested with arm-none-linux-gnu for mainline
and 4.9 for a variety of multilib flags.

OK for mainline and 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.target/arm/pr48784.c: Skip for thumb1 multilib.
* gcc.target/arm/pr59985.c: Likewise.

Index: gcc/testsuite/gcc.target/arm/pr58784.c
===
--- gcc/testsuite/gcc.target/arm/pr58784.c  (revision 437379)
+++ gcc/testsuite/gcc.target/arm/pr58784.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm_thumb1 } { "*" } { "" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -O2" } */
 
 typedef struct __attribute__ ((__packed__))
Index: gcc/testsuite/gcc.target/arm/pr59985.C
===
--- gcc/testsuite/gcc.target/arm/pr59985.C  (revision 437379)
+++ gcc/testsuite/gcc.target/arm/pr59985.C  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm_thumb1 } { "*" } { "" } } */
 /* { dg-options "-g -fcompare-debug -O2 -march=armv7-a -mtune=cortex-a9 
-mfpu=vfpv3-d16 -mfloat-abi=hard" } */
 
 extern void *f1 (unsigned long, unsigned long);

[testsuite patch] skip an ARM run test if not using neon hardware

[Janis Johnson]

Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
generate neon instructions, but it should also check that the test will
be run using hardware that supports neon, which this patch adds.
Tested with arm-none-linux-gnu for mainline and 4.9 with a variety of
multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.target/arm/neon-vext-execute.c: Skip if the test won't run
on Neon hardware.

Index: gcc/testsuite/gcc.target/arm/neon-vext-execute.c
===
--- gcc/testsuite/gcc.target/arm/neon-vext-execute.c(revision 437379)
+++ gcc/testsuite/gcc.target/arm/neon-vext-execute.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target arm_neon_ok } */
+/* { dg-require-effective-target arm_neon_hw } */
 /* { dg-require-effective-target arm_little_endian } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_neon } */

[testsuite patch] don't add ARM options for a thumb1 multilib

[Janis Johnson]

Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
those options conflict with flags for a thumb1 multilib.  Don't add
the extra ARM flags for a thumb1 multilib.  Tested with arm-none-linux-gnu
for mainline and 4.9 with a variety of multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.dg/pr59418.c: Don't add ARM options for a Thumb1 multilib.

Index: gcc/testsuite/gcc.dg/pr59418.c
===
--- gcc/testsuite/gcc.dg/pr59418.c  (revision 437379)
+++ gcc/testsuite/gcc.dg/pr59418.c  (working copy)
@@ -3,7 +3,7 @@
 
 /* { dg-do compile } */
 /* { dg-options "-Os -g" } */
-/* { dg-options "-march=armv7-a -mfloat-abi=hard -Os -g" { target arm*-*-* } } 
*/
+/* { dg-options "-march=armv7-a -mfloat-abi=hard -Os -g" { target { arm*-*-* 
&& { ! arm_thumb1 } } } } */
 
 extern int printf (const char *__format, ...);
 

[testsuite patch] add __ARM_ARCH check for arm_v8_neon_ok

[Janis Johnson]

The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
is not 8 or greater, but then some tests fail because intrinsic functions
used in the test have not been declared.  This patch requires that
__ARM_ARCH be 8 or greater.  Tested for arm-none-linux-gnu for mainline
and 4.9 with a variety of multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* lib/target/supports.exp
(check_effective_target_arm_v8_neon_ok_nocache): Check for armv8
or later.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 213831)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -2578,6 +2578,9 @@
 if { [check_effective_target_arm32] } {
foreach flags {"" "-mfloat-abi=softfp" "-mfpu=neon-fp-armv8" 
"-mfpu=neon-fp-armv8 -mfloat-abi=softfp"} {
if { [check_no_compiler_messages_nocache arm_v8_neon_ok object {
+   #if __ARM_ARCH < 8
+   #error not armv8 or later
+   #endif
#include "arm_neon.h"
void
foo ()

Re: [testsuite patch] add __ARM_ARCH check for arm_v8_neon_ok

[Janis Johnson]

On 08/14/2014 01:06 AM, Ramana Radhakrishnan wrote:
> On Mon, Aug 11, 2014 at 11:01 PM, Janis Johnson
>  wrote:
>> The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
>> is not 8 or greater, but then some tests fail because intrinsic functions
>> used in the test have not been declared.  This patch requires that
>> __ARM_ARCH be 8 or greater.  Tested for arm-none-linux-gnu for mainline
>> and 4.9 with a variety of multilib flags.
> 
> 
> Out of curiosity  - A number of tests are gated off by the target
> triplet arm*-*-*eabi* , I wonder how many of them actually run if you
> test with arm-none-linux-gnu . Also given this is the pre-EABI linux
> triplet, so I'd prefer not to conflate this with the use of the
> triplet arm-none-linux-gnueabi(hf).
> 

I hadn't noticed those but yes, they are run for arm-none-linux-gnueabi.
The effective-target arm_eabi checks for __ARM_EABI__, which is also true
for arm-none-linux-gnueabi.

I was wrong about my upstream testing in this case; I used arm-none-eabi,
and testing with our sources used both arm-none-eabi and arm-none-linux-gnueabi.

Janis

Re: [testsuite patch] add code to arm_thumbX_ok to exercise ABI

[Janis Johnson]

On 08/18/2014 07:36 AM, Christophe Lyon wrote:
> On 8 August 2014 02:30, Janis Johnson  wrote:
>> Running an arm-none-eabi test that adds "-mthumb" for a multilib that
>> uses "-march=armv5te -mfloat-abi=hard" works fine if the test doesn't
>> have any calls, but if it does then the effective-target checks for
>> arm_thumb1_ok and arm_thumb2_ok pass but the test's compile step fails
>> with "sorry, unimplemented: Thumb-1 hard-float VFP ABI".
>>
>> This patch adds code to those effective-target checks to exercise
>> argument handling and causes them to fail for the multilib flags
>> listed above.  Tested by running gcc.target/arm tests with a variety
>> of multilib flags.  OK for mainline and the 4.9 branch?
>>
>> Janis
> 
> Some time ago (https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01501.html)
> I suggested to add similar stuff to check_effective_target_arm_arch_FUNC_ok
> for similar reasons.
> 
> Do you agree?
> 

I agree but I prefer to have one of the ARM maintainers approve changes
like that; we sometimes have different philosophies about how to handle
additional options in tests.

Janis

[testsuite patch] another fix to arm_v8_neon_ok

[Janis Johnson]

My recent patch to check_effective_target_arm_v8_neon_ok_nocache didn't
take into account that when compiling the test itself, the option
"-march=armv8-a" is added to the flags used for the effective-target
check, so it caused more multilibs to be skipped than needed to be.

This patch uses "march=armv8-a" to compile the code in that check,
allowing multilibs that don't use conflicting options to run, and pass,
tests that are gated by it as they did before my patch went in.

Tested with gcc.target/neon tests for mainline arm-none-eabi with many
sets of multilib options; OK for mainline and 4.9?

Janis
2014-08-18  Janis Johnson  

gcc/testsuite/
* lib/target-supports.exp 
(check_effective_target_arm_v8_neon_ok_nocache):
Add "-march-armv8-a" to compile flags.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 214084)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -2587,7 +2587,7 @@
{
  __asm__ volatile ("vrintn.f32 q0, q0");
}
-   } "$flags"] } {
+   } "$flags -march=armv8-a"] } {
set et_arm_v8_neon_flags $flags
return 1
}

Re: [patch] [arm] ARM Cortex-M3/M4 tuning

[Janis Johnson]

On 11/12/2013 10:20 PM, Joey Ye wrote:
> Janis, can you please take a look at test case changes.
> 
> Thanks,
> Joey

They look fine.

Janis

>> -Original Message-
>> From: Ramana Radhakrishnan
>> Sent: Friday, November 08, 2013 17:11
>> To: Joey Ye
>> Cc: gcc-patches@gcc.gnu.org; jani...@codesourcery.com
>> Subject: Re: [patch] [arm] ARM Cortex-M3/M4 tuning
>>
 ChangeLog:

  2013-11-01  Julian Brown  
  Joey Ye  

  * config/arm/arm.c (arm_cortex_m_branch_cost): New.
  (arm_v7m_tune): New.
  (arm_*_tune): Add comments for Sched adj cost.
>>
>> List all names here please rather than a regexp.
>>
  * config/arm/arm-cores.def (cortex-m4, cortex-m3):
  Use arm_v7m_tune tuning.

>>
>> The ARM parts are ok but I'd like a testsuite maintainer to look at the
>> testsuite changes before committing.
>>
>> regards
>> Ramana
>>
 testsuite:
  2013-11-01  Joey Ye  

  * gcc.dg/tree-ssa/forwprop-28.c: Disable for cortex_m.
  * gcc.dg/tree-ssa/vrp47.c: Likewise.
  * gcc.dg/tree-ssa/vrp87.c: Likewise.
  * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Ignore for cortex_m.
  * gcc.dg/tree-ssa/ssa-vrp-thread-1.c: Likewise.

MAINTAINERS: resign as testsuite maintainer, update address

[Janis Johnson]

I retired from Mentor Graphics 3 weeks ago and have no immediate plans
to be active in GCC, so I'm resigning as a testsuite maintainer.  I'm
leaving myself under Write After Approval with my personal email address
so people can find me.

Five years ago while between jobs I got an individual FSF copyright
assignment; is that still valid?

Janis


gcc-20150202-1
Description: Binary data

Re: [patch, testsuite] don't use dg-run in gcc.dg/vect tests

[Janis Johnson]

On 09/25/2014 04:48 PM, Sandra Loosemore wrote:
> On 09/25/2014 02:04 PM, Sandra Loosemore wrote:
>> While doing some arm-none-eabi testing, I noticed that a bunch of
>> gcc.dg/vect tests were causing the target to hang from trying to execute
>> code compiled with "-mfpu=neon -mfloat-abi=softfp", on a target that
>> doesn't support those instructions.  And, this was caused by tests
>> specifying "dg-do run" unconditionally instead of allowing the
>> dg-require-effective-target mechanism to decide whether the target can
>> run code compiled with the vectorization options added by vect.exp.
>>
>> This patch fixes the bad tests.  OK to check in?
> 
> Janis pointed out to me off-list that I did not need to add new 
> dg-require-effective-target stuff; the run vs. just compile decision is 
> made by vect.exp independently of that.  Here's a revised patch.  Is 
> this one OK to check in?
> 
> -Sandra
> 

Yes.  Tests in directories that have checks to determine whether the
default for "dg-do" should be "run" or "compile", like those in
gcc.dg/vect, should never specify "dg-do run".

Janis

> 
> 2014-09-25  Sandra Loosemore  
> 
>   gcc/testsuite/
>   * gcc.dg/vect/pr56933.c: Don't specify "dg-do run" explicitly.
>   * gcc.dg/vect/pr57705.c: Likewise.
>   * gcc.dg/vect/pr57741-2.c: Likewise.
>   * gcc.dg/vect/pr57741-3.c: Likewise.
>   * gcc.dg/vect/pr59591-1.c: Likewise.
>   * gcc.dg/vect/pr59591-2.c: Likewise.
>   * gcc.dg/vect/pr60196-1.c: Likewise.
>   * gcc.dg/vect/pr60196-2.c: Likewise.
>   * gcc.dg/vect/pr60276.c: Likewise.
>   * gcc.dg/vect/pr61680.c: Likewise.
>   * gcc.dg/vect/pr63148.c: Likewise.
>   * gcc.dg/vect/pr63189.c: Likewise.
>   * gcc.dg/vect/vect-mask-load-1.c: Likewise.
>   * gcc.dg/vect/vect-mask-loadstore-1.c: Likewise.
>   * gcc.dg/vect/vect-nop-move.c: Likewise.
>   * gcc.dg/vect/vect-simd-clone-10.c: Likewise.
>   * gcc.dg/vect/vect-simd-clone-12.c: Likewise.
> 
> 
> 

Re: [PATCH, ARM] Fix unrecognizable vector comparisons

[Janis Johnson]

On 07/08/2013 08:32 AM, Zhenqiang Chen wrote:
> On 8 July 2013 20:57, Ramana Radhakrishnan  wrote:
>> Not yet. Why is this not a problem in the LT / UNLT case ?
> 
>>From the context, after the first switch, only GE/LE/EQ might have
> operands[5] which is not REG (CONST0_RTX). For others including
> LT/UNLT, operands[5] should be REG.
> 
> if (!REG_P (operands[5]))
>   operands[5] = force_reg (mode, operands[5]);
> 
> For GE/LE/EQ, we only reverse LE. So only LE has issue.
> 
>> The testcase is not correctly written.
>>
>>
>> @@ -0,0 +1,16 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
>> -mfloat-abi=hard -S" } */
>>
>> dg-add-options arm_neon ?
>> dg-require-effective-target arm_neon ?
> 
> I will update it.

Please skip the test for multilibs whose flags include -mfpu or -mcpu options,
which would conflict with or override the options in the test.

Janis

> Thanks!
> -Zhenqiang
> 
>> On Wed, Jun 26, 2013 at 9:01 AM, Zhenqiang Chen
>>  wrote:
>>> On 18 June 2013 17:41, Ramana Radhakrishnan  wrote:
 On 06/18/13 09:50, Zhenqiang Chen wrote:
>
> Hi,
>
> During expand, function vcond inverses some CMP, e.g.
>
> a LE b -> b GE a
>
> But if "b" is "CONST0_RTX", "b GE a" will be an illegal insn.
>
> (insn 933 932 934 113 (set (reg:V4SI 1027)
>  (unspec:V4SI [
>  (const_vector:V4SI [
>  (const_int 0 [0])
>  (const_int 0 [0])
>  (const_int 0 [0])
>  (const_int 0 [0])
>  ])
>  (reg:V4SI 1023 [ vect_var_.49 ])
>  (const_int 1 [0x1])
>  ] UNSPEC_VCGE)) PUGHSlab/Mapping.c:567 -1
>   (nil))
>
> Refer https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1189445
> for more. And the bug also happens for FSF trunk.
>
> The similar issue
> (https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1163942)
> had fixed on AARCH64:
> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00581.html
>
> The patch is similar to the fix for aarch64.
>
> Bootstrap and no make check regression on Panda Board.
>
> Is it OK for trunk and 4.8?


 No, not without an appropriate set of testcases that exercise these cases.
>>>
>>> Thanks for the comments. Patch is updated with a test case.
>>>
>>> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
>>> index 2761adb..6d9f604 100644
>>> --- a/gcc/config/arm/neon.md
>>> +++ b/gcc/config/arm/neon.md
>>> @@ -1710,6 +1710,9 @@
>>>  case LE:
>>>  case UNLE:
>>>inverse = 1;
>>> +  /* Can not inverse "a LE 0" to "0 GE a".  */
>>> +  if (operands[5] == CONST0_RTX (mode))
>>> +   inverse = 0;
>>>/* Fall through.  */
>>>  case GT:
>>>  case UNGT:
>>> diff --git a/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> b/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> new file mode 100644
>>> index 000..8ce4b97
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/lp1189445.c
>>> @@ -0,0 +1,16 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O3 -mfpu=neon -mcpu=cortex-a9 -mthumb
>>> -mfloat-abi=hard -S" } */
>>> +
>>> +int id;
>>> +int
>>> +test (const long int *data)
>>> +{
>>> +  int i, retval;
>>> +  retval = id;
>>> +  for (i = 0; i < id; i++)
>>> +{
>>> +  retval &= (data[i] <= 0);
>>> +}
>>> +
>>> +  return (retval);
>>> +}
> 
> 

[testsuite] fix gcc.target/powerpc/sd-vsx.c and sd-pwr6.c

[Janis Johnson]

Tests gcc.target/powerpc/sd-vsx.c and sd-pwr6.c assume that decimal
floating point is supported on the target, but this is not true for
powerpc-none-eabi.  This obvious patch skips the test if dfp is
not supported; checked in for mainline.

Janis
2013-07-08  Janis Johnson  

* gcc.target/powerpc/sd-vsx.c: Require dfp.
* gcc.target/powerpc/sd-pwr6.c: Likewise.

Index: gcc.target/powerpc/sd-pwr6.c
===
--- gcc.target/powerpc/sd-pwr6.c(revision 200789)
+++ gcc.target/powerpc/sd-pwr6.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* powerpc-ibm-aix* } { "*" } { "" } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target dfp } */
 /* { dg-options "-O2 -mcpu=power6 -mhard-dfp" } */
 /* { dg-final { scan-assembler-not   "lfiwzx"   } } */
 /* { dg-final { scan-assembler-times "lfd"2 } } */
Index: gcc.target/powerpc/sd-vsx.c
===
--- gcc.target/powerpc/sd-vsx.c (revision 200789)
+++ gcc.target/powerpc/sd-vsx.c (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do compile { target { powerpc*-*-* } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* powerpc-ibm-aix* } { "*" } { "" } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-require-effective-target dfp } */
 /* { dg-options "-O2 -mcpu=power7 -mhard-dfp" } */
 /* { dg-final { scan-assembler-times "lfiwzx" 2 } } */
 /* { dg-final { scan-assembler-times "stfiwx" 1 } } */

[testsuite] fix gcc.target/powerpc/pr47197.c

[Janis Johnson]

Test gcc.target/powerpc/pr47197.c passes "-maltivec" without first
checking that the option is allowed on the target, which is not the case
for powerpc-eabispe.  This obvious patch fixes the problem by requiring
powerpc_altivec_ok; checked in on mainline and the 4.8 branch.

Janis
2013-07-08  Janis Johnson  

* gcc.target/powerpc/pr47197.c: Require powerpc_altivec_ok.

Index: gcc.target/powerpc/pr47197.c
===
--- gcc.target/powerpc/pr47197.c(revision 200621)
+++ gcc.target/powerpc/pr47197.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
 /* { dg-options "-maltivec" } */
 
 /* Compile-only test to ensure that expressions can be passed to

[testsuite] fix gcc.target/powerpc/ppc-spe64-1.c

[Janis Johnson]

The error message checked in gcc.target/powerpc/ppc-spe64-1.c changed
for GCC 4.8.  This obvious patch fixes the test to expecte the current
message; checked in for mainline and the 4.8 branch.

Janis
2013-07-08  Janis Johnson  

* gcc.target/powerpc/ppc-spe64-1.c: Update expected error message.

Index: gcc.target/powerpc/ppc-spe64-1.c
===
--- gcc.target/powerpc/ppc-spe64-1.c(revision 200621)
+++ gcc.target/powerpc/ppc-spe64-1.c(working copy)
@@ -4,4 +4,4 @@
 /* { dg-options "-m64" } */
 
 /* { dg-error "-m64 not supported in this configuration" "SPE not 64-bit" { 
target *-*-* } 0 } */
-/* { dg-error "64-bit E500 not supported" "64-bit E500" { target *-*-* } 0 } */
+/* { dg-error "64-bit SPE not supported" "64-bit SPE" { target *-*-* } 0 } */

[testsuite] fix powerpc alignment tests for eabi

[Janis Johnson]

Tests gcc.target/powerpc/20020118-1.c and
gcc.c-torture/execute/nest-align-1.c sometimes fail because they expect
a stack alignment that is greater than that required for powerpc-eabi.
This patch forces stack alignment to 128 bits by passing "-mno-eabi".

Is this OK for mainline and the 4.8 branch, or would it  be better to
skip these tests for powerpc-*-eabi*?

Janis
2013-07-08  Janis Johnson  

* gcc.target/powerpc/20020118-1.c: Force 128-bit stack alignment
for EABI targets.
* gcc.c-torture/execute/nest-align-1.x: Likewise.

Index: gcc.target/powerpc/20020118-1.c
===
--- gcc.target/powerpc/20020118-1.c (revision 200621)
+++ gcc.target/powerpc/20020118-1.c (working copy)
@@ -1,6 +1,8 @@
 /* { dg-do run { target powerpc*-*-* } }*/
 /* VxWorks only guarantees 64 bits of alignment (STACK_BOUNDARY == 64).  */
 /* { dg-skip-if "" { "powerpc*-*-vxworks*" } { "*" } { "" } } */
+/* Force 128-bit stack alignment for eabi targets.  */
+/* { dg-options "-mno-eabi" { target powerpc*-*-eabi* } } */
 
 /* Test local alignment.  Test new target macro STARTING_FRAME_PHASE.  */
 /* Origin: Aldy Hernandez .  */
Index: gcc.c-torture/execute/nest-align-1.x
===
--- gcc.c-torture/execute/nest-align-1.x(revision 0)
+++ gcc.c-torture/execute/nest-align-1.x(revision 0)
@@ -0,0 +1,5 @@
+# Force bigger stack alignment for PowerPC EABI targets.
+if { [istarget "powerpc-*-eabi*"] } {
+set additional_flags "-mno-eabi"
+}
+return 0

[testsuite] skip gcc.target/powerpc-tfmode_off.c for eabi

[Janis Johnson]

Test gcc.target/powerpc-tfmode_off.c fails for powerpc-eabi* targets,
which do not support TFmode.  This patch skips the test for
powerpc-*-eabi*.

OK for mainline and the 4.8 branch?

Janis
2013-07-08  Janis Johnson  

* gcc.target/powerpc/tfmode_off.c: Skip for EABI targets.

Index: gcc.target/powerpc/tfmode_off.c
===
--- gcc.target/powerpc/tfmode_off.c (revision 200621)
+++ gcc.target/powerpc/tfmode_off.c (working copy)
@@ -1,5 +1,6 @@
 /* { dg-do assemble } */
 /* { dg-skip-if "" { powerpc-ibm-aix* } { "*" } { "" } } */
+/* { dg-skip-if "" { powerpc-*-eabi* } { "*" } { "" } } */
 /* { dg-options "-O2 -fno-align-functions -mtraceback=no -save-temps" } */
 
 typedef float TFmode __attribute__ ((mode (TF)));

[patch] fix libgcc configure for powerpc-*-eabispe

[Janis Johnson]

Tests for powerpc-none-eabispe fail with lots of undefined symbols for
_*_df and for __extendsfdf2, __make_fp, and __unordsf2.  This patch
includes float support in libgcc for the target and eliminates those
test failures.

OK for mainline and the 4.8 branch?  Tested with a cross build of
powerpc-none-eabispe from i686-pc-linux-gnu.

Janis
2013-07-09  Janis Johnson  

* config.host (powerpc-*-eabispe*: Add t-fdpbit to tmake_file.

Index: libgcc/config.host
===
--- libgcc/config.host  (revision 200845)
+++ libgcc/config.host  (working copy)
@@ -869,7 +869,7 @@
tmake_file="$tmake_file rs6000/t-netbsd rs6000/t-crtstuff"
;;
 powerpc-*-eabispe*)
-   tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr 
rs6000/t-crtstuff t-crtstuff-pic"
+   tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr 
rs6000/t-crtstuff t-crtstuff-pic t-fdpbit"
extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o 
crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
;;
 powerpc-*-eabisimaltivec*)

Re: Ping: testsuite patches ({1,2,6,10,12}/14)

[Janis Johnson]

On 08/14/2013 08:55 AM, Joern Rennecke wrote:
> These patches have not been reviewed for more than three weeks:
> 
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00807.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00812.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00816.html
> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00819.html

These are OK.

> http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00895.html

I'd prefer to have someone else review this patch, which replaces
-gdwarf-2 with -gdwarf.

Janis

[testsuite] fix directives in gcc.target/arm/atomic-*.c tests

[Janis Johnson]

As the test directives section of the GCC internals manual says:

   The order in which test directives appear in a test can be important:
   directives local to GCC sometimes override information used by the
   DejaGnu directives, which know nothing about the GCC directives, so
   the DejaGnu directives must precede GCC directives.

This patch fixes several tests in gcc.target/arm to move dg-do to before
dg-require-effective-target so the test will be skipped as expected.
Tested with several sets of flags with arm-none-eabi, checked in as
obvious.

Janis
2013-08-14  Janis Johnson  

* gcc.target/arm/atomic-comp-swap-release-acquire.c: Move dg-do
to be the first test directive.
* gcc.target/arm/atomic-op-acq_rel.c: Likewise.
* gcc.target/arm/atomic-op-acquire.c: Likewise.
* gcc.target/arm/atomic-op-char.c: Likewise.
* gcc.target/arm/atomic-op-consume.c: Likewise.
* gcc.target/arm/atomic-op-int.c: Likewise.
* gcc.target/arm/atomic-op-relaxed.c: Likewise.
* gcc.target/arm/atomic-op-release.c: Likewise.
* gcc.target/arm/atomic-op-seq_cst.c: Likewise.
* gcc.target/arm/atomic-op-short.c: Likewise.

Index: testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c
===
--- testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c (revision 
201513)
+++ testsuite/gcc.target/arm/atomic-comp-swap-release-acquire.c (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-acq_rel.c
===
--- testsuite/gcc.target/arm/atomic-op-acq_rel.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-acq_rel.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-acquire.c
===
--- testsuite/gcc.target/arm/atomic-op-acquire.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-acquire.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-char.c
===
--- testsuite/gcc.target/arm/atomic-op-char.c   (revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-char.c   (working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-consume.c
===
--- testsuite/gcc.target/arm/atomic-op-consume.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-consume.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-int.c
===
--- testsuite/gcc.target/arm/atomic-op-int.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-int.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-relaxed.c
===
--- testsuite/gcc.target/arm/atomic-op-relaxed.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-relaxed.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-release.c
===
--- testsuite/gcc.target/arm/atomic-op-release.c(revision 201513)
+++ testsuite/gcc.target/arm/atomic-op-release.c(working copy)
@@ -1,5 +1,5 @@
+/* { dg-do compile } */
 /* { dg-require-effective-target arm_arch_v8a_ok } */
-/* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_arch_v8a } */
 
Index: testsuite/gcc.target/arm/atomic-op-seq_cst.c
==

[testsuite] skip gcc.target/arm/pr19599.c for -mthumb

[Janis Johnson]

This patch skips an arm test if the multilib flags include "-mthumb",
which would override the "-marm" used for the test.  Tested with
several sets of flags for arm-none-eabi and checked in as obvious.

Janis
2013-04-24  Janis Johnson  

* arm-none-linux-eabi.inc (print_eembc_scale_factor): decrease
for rexella.

Index: release-configs/arm-none-linux-eabi.inc
===
--- release-configs/arm-none-linux-eabi.inc (revision 409607)
+++ release-configs/arm-none-linux-eabi.inc (working copy)
@@ -51,6 +51,9 @@
(averil*)
echo 2
;;
+   (rexella*)
+   echo 2
+   ;;
(*)
echo 100
;;

Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Janis Johnson]

On 02/27/2013 09:29 AM, Julian Brown wrote:
> Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
> ===
> --- gcc/testsuite/gcc.dg/vect/slp-cond-3.c(revision 196170)
> +++ gcc/testsuite/gcc.dg/vect/slp-cond-3.c(working copy)
> @@ -79,6 +79,6 @@ int main ()
>return 0;
>  }
>  
> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> } } */
> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" 
> { xfail { ! vect_unpack } } } } */
>  /* { dg-final { cleanup-tree-dump "vect" } } */
>  

If this and other modified checks only fail for ARM big-endian then they
should check for that so they don't XPASS for other targets.  It's also
possible now to do things like { target vect_blah xfail arm_big_endian },
which might be useful for some tests.

Janis

Re: [PATCH] xfail g++.old-deja/g++.pt/ptrmem6.C for aarch64

[Janis Johnson]

On 02/27/2013 08:47 AM, Marcus Shawcroft wrote:
> This aarch64 FAIL is known to be an issue on targets that define
> TARGET_PTRMEMFUNC_VBIT_LOCATION to ptrmemfunc_vbit_in_delta
> 
> The issue was silenced early 2012 on arm and mips with an xfail, this
> patch adds aarch64 to the list.
> 
> The relevant upstream thread around the xfail for arm and mips is here:
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01046.html
> 
> OK?
> 
> /Marcus
> 
> 2013-02-27  Marcus Shawcroft  
> 
> * g++.old-deja/g++.pt/ptrmem6.C(main): Add xfail aarch64*-*-*.
> 

OK.

Janis

Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Janis Johnson]

On 02/28/2013 02:06 AM, Julian Brown wrote:
> On Wed, 27 Feb 2013 11:04:04 -0800
> Janis Johnson  wrote:
> 
>> On 02/27/2013 09:29 AM, Julian Brown wrote:
>>> Index: gcc/testsuite/gcc.dg/vect/slp-cond-3.c
>>> ===
>>> --- gcc/testsuite/gcc.dg/vect/slp-cond-3.c  (revision 196170)
>>> +++ gcc/testsuite/gcc.dg/vect/slp-cond-3.c  (working copy)
>>> @@ -79,6 +79,6 @@ int main ()
>>>return 0;
>>>  }
>>>  
>>> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP"
>>> 1 "vect" } } */ +/* { dg-final { scan-tree-dump-times "vectorizing
>>> stmts using SLP" 1 "vect" { xfail { ! vect_unpack } } } } */ /*
>>> { dg-final { cleanup-tree-dump "vect" } } */ 
>>
>> If this and other modified checks only fail for ARM big-endian then
>> they should check for that so they don't XPASS for other targets.
>> It's also possible now to do things like { target vect_blah xfail
>> arm_big_endian }, which might be useful for some tests.
> 
> I don't think I understand -- my expectation was e.g. that that test
> would fail for any target which doesn't support vect_unpack. Surely
> you'd only get an XPASS if the test passed when vect_unpack was not
> true?

Right.  Please ignore my mail, I was confused. 

> I'm not sure why checking for a particular architecture-specific
> predicate would be preferable to checking that a general feature is
> supported. As time progresses, it might well be that e.g. vect_unpack
> becomes supported for big-endian ARM, at which point we shouldn't need
> to edit all the individual tests again...

Right.  Once again, I was confused, ignore me.

Janis

Re: [patch testsuite]: Fix some tests for LLP64 targets

[Janis Johnson]

On 03/06/2013 10:00 AM, Kai Tietz wrote:
> Hello,
> 
> this patch fixes some regressions in testsuite for x64-targets.
> 
> ChangeLog
> 
> 2013-03-06  Kai Tietz  
> 
>   * gcc.dg/lto/20090914-2_0.c: Skip for mingw and cygwin
>   targets.
>   * gcc.dg/lto/20091013-1_1.c: Set x64-mingw as xfail.
>   * gcc.dg/lto/20091013-1_2.c: Likewise.
>   * gcc.dg/pr31490.c: Adjust for LLP64 targets.
> 
> Ok for apply?
> 
> Regards,
> Kai

OK.

Janis

Re: [Patch AArch64] Add support for vectorizable standard math patterns.

[Janis Johnson]

On 12/17/2012 06:23 AM, Richard Earnshaw wrote:
> On 27/11/12 20:47, Mike Stump wrote:
>> On Nov 27, 2012, at 8:51 AM, James Greenhalgh  
>> wrote:
>>> In particular, we add support for vectorizing across:
>>>
>>> ceil (), ceilf (), lceil (),
>>
>>> We add testcases ensuring that each of the expected functions are
>>> vectorized. As the i386 and rs6000 backends both ostensibly support
>>> these optimisations we add these tests to the generic testsuites, but
>>> only wire them up for AArch64. As a target may support any subset of
>>> these vectorizations we need a check_effective_target macro for
>>> each of them.
>>>
>>> Because of this change to the generic test code I've CCed Janis
>>> Johnson and Mike Stump.
>>
>> Gosh…  leaves a bad taste in my mouth.I see why you did it that way…  
>> So, let me just ping folks, anyone see a better way to do this?  If no one 
>> admits to having a better solution, I'll approve it.  Let's give them a few 
>> days to come up with something concrete, if they fail, Ok.
>>
> 
> 
> I've been pondering this one for a bit.  I wonder if having a single 
> function
> 
> check_effective_target_vect_libcall(func)
> 
> where func is the name of the function you needed to check, might be 
> cleaner.
> 
> The idea is that the one function might access an array (set up on the 
> first call) and then just use "info exists et_vect_libcalls(func)" to do 
> the body of the check.
> 
> Not entirely sure my expect foo is good enough to code this up, though.
> 
> R.
> 

I suspect that the Tcl code to support an array would end up being
messier and less maintainable.

Janis

[testsuite] replace gcc.target/arm/ftest-*.c with compile-only tests

[Janis Johnson]

The gcc.target/arm/ftest-*.c tests check various macros that are set for
ARM targets by setting flags based on preprocessor directives that check
those macros.  The tests are skipped if the current test platform
doesn't support executing programs for the architecture for which flags
are being checked.  There are several problems with these tests:

  o  There are problems with the arm_arch_v*_multilib effective target
 checks as described in PR testsuite/55780.

  o  Tests for arm mode are skipped if the currently multilib generates
 THUMB mode by default, but they only need to be skipped if the
 multilib flags include -mthumb that would override the -marm
 specified in test options.

  o  The tests are not skipped if multilib flags use -march=* that would
 override the test options.

When checking preprocessor builtins there is no need to execute a test;
the checking can all be done during preprocessing.  This patch replaces
the gcc.target/arm/ftest-*.c tests with compile-only tests that fail to
compile if macros are defined when they should not be, or have the
wrong values.  All tests can now be run without depending on the target
hardware.

Tested with several sets of multilib options for arm-none-eabi and
arm-none-linux-gnueabi.  OK?

Janis

P.S.  I don't know why, but the original thumb tests require arm_eabi
and the arm tests don't; I kept that restraint.
2012-12-21  Janis Johnson  

* gcc.target/arm/ftest-support.h: Replace for compile-only tests.
* gcc.target/arm/ftest-support-arm.h: Delete.
* gcc.target/arm/ftest-support-thumb.h: Delete.
* gcc.target/arm/ftest-armv4-arm.c: Replace with compile-only test.
* gcc.target/arm/ftest-armv4t-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5t-arm.c: Likewise.
* gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5te-arm.c: Likewise.
* gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6-arm.c: Likewise.
* gcc.target/arm/ftest-armv6-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6k-arm.c: Likewise.
* gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
* gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6z-arm.c: Likewise.
* gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7a-arm.c: Likewise.
* gcc.target/arm/ftest-armv7a-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7em-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7r-arm.c: Likewise.
* gcc.target/arm/ftest-armv7r-thumb.c: Likewise.
* gcc.target/arm/ftest-armv8a-arm.c: Likewise.
* gcc.target/arm/ftest-armv8a-thumb.c: Likewise.

Index: gcc.target/arm/ftest-support.h
===
--- gcc.target/arm/ftest-support.h  (revision 194619)
+++ gcc.target/arm/ftest-support.h  (working copy)
@@ -1,84 +1,156 @@
-#if 0
-#define INTERNAL_DEBUG 1
+/* For each of several ARM architecture features, check that relevant
+   macros are defined or not, and that they have the expected values.  */
+
+#ifdef NEED_ARM_ARCH
+# ifdef __ARM_ARCH
+#  if __ARM_ARCH != VALUE_ARM_ARCH
+#   error __ARM_ARCH has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH
+#  error __ARM_ARCH is defined but should not be
+# endif
 #endif
 
-#ifdef INTERNAL_DEBUG
-#include 
+#ifdef NEED_ARM_ARCH_ISA_ARM
+# ifdef __ARM_ARCH_ISA_ARM
+#  if __ARM_ARCH_ISA_ARM != VALUE_ARM_ARCH_ISA_ARM
+#   error __ARM_ARCH_ISA_ARM has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH_ISA_ARM is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH_ISA_ARM
+#  error __ARM_ARCH_ISA_ARM is defined but should not be
+# endif
 #endif
 
-extern void abort (void);
+#ifdef NEED_ARM_ARCH_ISA_THUMB
+# ifdef __ARM_ARCH_ISA_THUMB
+#  if __ARM_ARCH_ISA_THUMB != VALUE_ARM_ARCH_ISA_THUMB
+#   error __ARM_ARCH_ISA_THUMB has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH_ISA_THUMB is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH_ISA_THUMB
+#  error __ARM_ARCH_ISA_THUMB is defined but should not be
+# endif
+#endif
 
-enum architecture {
-  ARCH_V4 = 0,
-  ARCH_V4T,
-  ARCH_V5T,
-  ARCH_V5TE,
-  ARCH_V6,
-  ARCH_V6K,
-  ARCH_V6T2,
-  ARCH_V6Z,
-  ARCH_V6M,
-  ARCH_V7A,
-  ARCH_V7R,
-  ARCH_V7M,
-  ARCH_V7EM,
-  ARCH_V8A,
-  ARCH_COUNT
-};
+#ifdef NEED_ARM_ARCH_PROFILE
+# ifdef __ARM_ARCH_PROFILE
+#  if __ARM_ARCH_PROFILE != VALUE_ARM_ARCH_PROFILE
+#   error __ARM_ARCH_PROFILE has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH_PROFILE is not defined but should be
+# endif

[v3 testsuite] gdb-test.exp: catch error running gdb command

[Janis Johnson]

The libstdc++ prettyprinter tests require a certain level of support
from GDB, and the check for that GDB support runs a command that
includes a quoted string.  This causes an error from the testsuite
infrastructure for embedded processors whose board support passes
commands through additional levels of procedures that lose the
backslashes that escape the quotes.  Adding more backslashes wouldn't
work because it would prevent the command from working for the majority
of boards.  I can't figure out a real solution to the problem.

Rather than gdb_version_check resulting in an error for boards that
pass a command through additional levels of procedure calls, this
patch lets it catch the error so that it can fail gracefully and the
tests will be reported as UNSUPPORTED.  This will skip the tests for
a relatively small number of test setups.

OK for trunk?

Janis
2013-01-03  Janis Johnson  

* testsuite/lib/gdb-test.exp (gdb_batch_check): Catch error running
gdb command.

Index: libstdc++-v3/testsuite/lib/gdb-test.exp
===
--- libstdc++-v3/testsuite/lib/gdb-test.exp (revision 194619)
+++ libstdc++-v3/testsuite/lib/gdb-test.exp (working copy)
@@ -219,7 +219,9 @@
 set gdb_name $::env(GUALITY_GDB_NAME)
 set cmd "$gdb_name -nw -nx -quiet -batch -ex \"$command\""
 send_log "Spawning: $cmd\n"
-set res [remote_spawn target "$cmd"]
+if [catch { set res [remote_spawn target "$cmd"] } ] {
+   return 0
+}
 if { $res < 0 || $res == "" } {
return 0
 }

PING: gcc.target/arm: skip 5 tests for flag conflicts

[Janis Johnson]

Richard,

Back in September I submitted a patch to fix five ARM tests in
 .

You responded in < http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00972.html>
and I answered your questions in a reply.

The first of the modified tests doesn't need to be changed, at least for
the sets of flags with which I usually test, but the others all conflict
with some of my multilib flags.  Note that the tests will be run with
the specified options for a default multilib, or one that doesn't use
any of the same options that are needed for the multilib.

Can I check those in now?

Janis

PING: replace gcc.target/arm/ftest-*.c with compile-only tests

[Janis Johnson]

Richard,

In December I submitted a patch to replace ftest*.c in gcc.target/arm with
compile-only tests: .
There has been no response to the patch.

One reason for the replacement is that the arch_v*_multilib effective target
checks don't do what they're supposed to do and sometimes cause the simulator
and QEMU to hang, as described in PR testsuite/55780.

Please review the patch or encourage someone to fix the effective target
checks.

Janis

[testsuite] skip ARM tests fma.c and fma-sp.c for conflicting options

[Janis Johnson]

The options specified for gcc.target/arm/fma.c and fma-sp.c can conflict
with several multilib options.  This patch skips the tests for multilibs
with conflicting options, and it adds option "-mfloat-abi=hard" which is
needed for the test.

OK for trunk?

Janis
2013-01-14  Janis Johnson  

* gcc.target/arm/fma.c: Skip for conflicting multilib options.
* gcc.target/arm/fma-sp.c: Likewise.

Index: gcc.target/arm/fma.c
===
--- gcc.target/arm/fma.c(revision 195178)
+++ gcc.target/arm/fma.c(working copy)
@@ -1,5 +1,9 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcpu=cortex-a15 -mfpu=vfpv4" } */
+/* { dg-skip-if "avoid conflicts with multilib options" { ! arm_thumb2_ok } { 
"-mthumb" } { "" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mcpu=*" 
} { "-mcpu=cortex-a15" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mfpu=*" 
} { "-mfpu=vfpv4" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
+/* { dg-options "-O2 -mcpu=cortex-a15 -mfpu=vfpv4 -mfloat-abi=hard" } */
 
 #include "fma.h"
 
Index: gcc.target/arm/fma-sp.c
===
--- gcc.target/arm/fma-sp.c (revision 195178)
+++ gcc.target/arm/fma-sp.c (working copy)
@@ -1,5 +1,9 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb" } */
+/* { dg-skip-if "avoid conflicts with multilib options" { ! arm_thumb2_ok } { 
"-march=*" } { "" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mcpu=*" 
} { "-mcpu=cortex-m4" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { "-mfpu=*" 
} { "-mfpu=fpv4-sp-d16" } } */
+/* { dg-skip-if "avoid conflicts with multilib options" { *-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
+/* { dg-options "-O2 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb 
-mfloat-abi=hard" } */
 
 #include "fma.h"
 

[testsuite] fix ARM test gcc.target/arm/neon-vld1_dupQ.c

[Janis Johnson]

Test gcc.target/arm/neon-vld1_dupQ.c started failing with r194594, a C
front end change that causes the test to get warnings.  The test passes
local variables of type int64x1_t to functions declared with arguments
of type int64_t.  This patch casts the values passed to those arguments.
It's possible that the patch invalidates the intent of the test, so I've
copied the test's author.

OK for trunk?

Janis

[testsuite] remove ARM big-endian from some vect effective targets

[Janis Johnson]

As described in PR testsuite/54622, lots of tests from gcc.dg/vect fail
for big-endian ARM, apparently with bits of vectorization support
disabled here and there.  This patch removes big-endian ARM from

check_effective_target_vect_perm_byte
check_effective_target_vect_perm_short
check_effective_target_vect_widen_mult_qi_to_hi_pattern,
check_effective_target_vect64

and makes check_effective_target_vect_widen_sum_qi_to_hi return 1 for
ARM.  For each individual change there are tests that no longer fail
and no tests that regress.

Tested for arm-none-eabi with several multilibs; OK for trunk?

Janis
2013-01-15  Janis Johnson  

PR testsuite/54622

* lib/target-supports.exp (check_effective_target_vect_perm_byte,
check_effective_target_vect_perm_short,
check_effective_target_vect_widen_mult_qi_to_hi_pattern,
check_effective_target_vect64): Return 0 for big-endian ARM.
(check_effective_target_vect_widen_sum_qi_to_hi): Return 1 for ARM.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 195178)
+++ lib/target-supports.exp (working copy)
@@ -3082,7 +3082,8 @@
 verbose "check_effective_target_vect_perm_byte: using cached result" 2
 } else {
 set et_vect_perm_byte_saved 0
-if { [is-effective-target arm_neon_ok]
+if { ([is-effective-target arm_neon_ok]
+ && [is-effective-target arm_little_endian])
 || [istarget aarch64*-*-*]
 || [istarget powerpc*-*-*]
  || [istarget spu-*-*] } {
@@ -3105,7 +3106,8 @@
 verbose "check_effective_target_vect_perm_short: using cached result" 2
 } else {
 set et_vect_perm_short_saved 0
-if { [is-effective-target arm_neon_ok]
+if { ([is-effective-target arm_neon_ok]
+ && [is-effective-target arm_little_endian])
 || [istarget aarch64*-*-*]
 || [istarget powerpc*-*-*]
  || [istarget spu-*-*] } {
@@ -3175,6 +3177,7 @@
 } else {
 set et_vect_widen_sum_qi_to_hi_saved 0
if { [check_effective_target_vect_unpack] 
+|| [check_effective_target_arm_neon_ok]
 || [istarget ia64-*-*] } {
 set et_vect_widen_sum_qi_to_hi_saved 1
}
@@ -3282,7 +3285,9 @@
 } else {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 0
 if { [istarget powerpc*-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
+  || ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 1
 }
 }
@@ -3307,7 +3312,9 @@
   || [istarget ia64-*-*]
   || [istarget i?86-*-*]
   || [istarget x86_64-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
+  || ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
 set et_vect_widen_mult_hi_to_si_pattern_saved 1
 }
 }
@@ -3914,7 +3921,9 @@
 verbose "check_effective_target_vect64: using cached result" 2
 } else {
 set et_vect64_saved 0
-if { ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) } {
+if { ([istarget arm*-*-*]
+ && [check_effective_target_arm_neon_ok]
+ && [check_effective_target_arm_little_endian]) } {
set et_vect64_saved 1
 }
 }

Re: [testsuite] fix ARM test gcc.target/arm/neon-vld1_dupQ.c

[Janis Johnson]

On 01/14/2013 03:04 PM, Janis Johnson wrote:
> Test gcc.target/arm/neon-vld1_dupQ.c started failing with r194594, a C
> front end change that causes the test to get warnings.  The test passes
> local variables of type int64x1_t to functions declared with arguments
> of type int64_t.  This patch casts the values passed to those arguments.
> It's possible that the patch invalidates the intent of the test, so I've
> copied the test's author.
> 
> OK for trunk?
> 
> Janis
> 

Here's the patch (thanks, Aldy!).
2013-01-14  Janis Johnson  

* gcc.target/arm/neon-vld1_dupQ.c: Use types that match function
prototypes.

Index: gcc.target/arm/neon-vld1_dupQ.c
===
--- gcc.target/arm/neon-vld1_dupQ.c (revision 195178)
+++ gcc.target/arm/neon-vld1_dupQ.c (working copy)
@@ -13,9 +13,9 @@
   int64x1_t input[2] = {(int64x1_t)0x0123456776543210LL,
(int64x1_t)0x89abcdeffedcba90LL};
   int64x1_t output[2] = {0, 0};
-  int64x2_t var = vld1q_dup_s64(input);
+  int64x2_t var = vld1q_dup_s64((int64_t *)input);
 
-  vst1q_s64(output, var);
+  vst1q_s64((int64_t *)output, var);
   if (output[0] != (int64x1_t)0x0123456776543210LL)
 abort();
   if (output[1] != (int64x1_t)0x0123456776543210LL)

[testsuite] add option to LTO flags for c-torture/execute/builtins tests

[Janis Johnson]

Most of the tests in gcc.c-torture/execute/builtins that use LTO torture
options "-O2 -flto -fuse-linker-plugin -fno-fat-lto-objects" fail to
link on EABI and ELF targets with multiple definitions for either memset
or strlen.  I filed PR testsuite/55994 and was told that the fix is to
run the tests for those targets with "-Wl,--allow-multiple-definition".
This patch adds that option to the flags used for the builtins tests
for EABI and ELF targets.

That option is probably also needed for RTEMS targets; I've copied Joel
so he can look into that.

Tested on arm-none-eabi; OK for mainline?

Janis
2013-01-15  Janis Johnson  

PR testsuite/55994
* gcc.c-torture/execute/builtins/builtins.exp: Add
-Wl,--allow-multiple-definition for eabi and elf targets.

Index: testsuite/gcc.c-torture/execute/builtins/builtins.exp
===
--- testsuite/gcc.c-torture/execute/builtins/builtins.exp   (revision 
195211)
+++ testsuite/gcc.c-torture/execute/builtins/builtins.exp   (working copy)
@@ -41,6 +41,10 @@
 if [istarget "powerpc-*-darwin*"] {
lappend additional_flags "-Wl,-multiply_defined,suppress"
 }
+if { [istarget *-*-eabi*]
+ || [istarget *-*-elf] } {
+   lappend additional_flags "-Wl,--allow-multiple-definition"
+}
 
 foreach src [lsort [find $srcdir/$subdir *.c]] {
 if {![string match *-lib.c $src] && [runtest_file_p $runtests $src]} {

Re: Fwd: summarize kfails in dg-extract-results.sh

[Janis Johnson]

On 01/15/2013 09:24 AM, David Blaikie wrote:
> For some reason KFAILs weren't being summarized by
> dg-extract-results.sh. I assume this was just an oversight, so here's
> a patch to add it alongside all the other result types.
> 
> I encountered this in the GDB test suite but was asked to submit the
> change upstream to GCC as GDB would prefer to avoid unnecessary local
> changes to the script & this change seems general enough to go in to
> GCC.
> 
> (As was pointed out by Pedro Alves on the gdb-patches list, KFAIL
> support was recently added by Doug Evans (
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00996.html ), so KPASS
> support seems like a natural complement)
> 
> I'm still a little fuzzy on the specifics of ChangeLog lines, but
> here's my attempt at one for this change:
> 
> * dg-extract-results.sh: Handle KPASSes.

OK.  I checked it in.

Janis

Re: dg-extract-results.sh truncates logs containing "Running "

[Janis Johnson]

On 01/15/2013 09:16 AM, David Blaikie wrote:
> & now with an actual GCC patch, instead of the GDB one - sorry about that.
> 
> On Tue, Jan 15, 2013 at 8:31 AM, David Blaikie  wrote:
>> The regex to detect the beginning of a test file execution was too
>> broad, matching any line beginning with "Running ". This caused
>> dg-extract-results.sh to truncate some test logs, including
>> gdb.base/help.exp in the GDB test suite (which tests "help running",
>> printing "Running the program.")
>>
>> The attached patch makes the match a little more precise to avoid
>> this. With this the exact count of PASS/FAIL/etc lines in the
>> dg-extract-results.sh output matches the counts in the computed
>> summary exactly for all cases I've seen.
>>
>> I encountered this in the GDB test suite but was asked to submit the
>> change upstream to GCC as GDB would prefer to avoid unnecessary local
>> changes to the script & this change seems general enough to go in to
>> GCC.
>>
>> I'm still a little fuzzy on the specifics of ChangeLog lines, but
>> here's my attempt at one for this change:
>>
>> * dg-extract-results.sh: constrain the start-of-log pattern to
>> avoid accidentally matching test content

OK.  I checked it in, with this ChangeLog entry:

2013-01-15  David Blaikie 

* dg-extract-results.sh: Constrain the start-of-log pattern.

Janis

[testsuite] fix loop index for gcc.dg/webizer.c

[Janis Johnson]

Execution of test gcc.dg/webizer.c fails with a segfault for
powerpc-eabi with the GNU simulator.  The test has an array of size 2
and accesses that array with indices of 1 and 2.  This patch fixes the
bounds of the loop index.

Tested on powerpc-none-eabi; OK for trunk?

Janis
2013-01-15  Janis Johnson  

* gcc.dg/webizer.c: Adjust loop variable.

Index: testsuite/gcc.dg/webizer.c
===
--- testsuite/gcc.dg/webizer.c  (revision 195216)
+++ testsuite/gcc.dg/webizer.c  (working copy)
@@ -21,7 +21,7 @@
 configure2()
 {
   block = 0 ;
-  for( row = 1 ; row <= numRows ; row++ ) {
+  for( row = 0 ; row < numRows ; row++ ) {
   block++ ;
 if( rowArray[row].endx1 > 0 ) {
   block++ ;

Re: [testsuite] fix loop index for gcc.dg/webizer.c

[Janis Johnson]

On 01/15/2013 02:01 PM, Jeff Law wrote:
> On 01/15/2013 02:57 PM, Janis Johnson wrote:
>> Execution of test gcc.dg/webizer.c fails with a segfault for
>> powerpc-eabi with the GNU simulator.  The test has an array of size 2
>> and accesses that array with indices of 1 and 2.  This patch fixes the
>> bounds of the loop index.
>>
>> Tested on powerpc-none-eabi; OK for trunk?
> Based on:
> 
> 
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01259.html
> 
> I think the the loop variables are fairly important.  I think we're less 
> likely to perturb the test by increasing the size of the array.
> 
> Jeff

Increasing the size of the array to 3 works.  OK to do that?

Janis

Re: [testsuite] replace gcc.target/arm/ftest-*.c with compile-only tests

[Janis Johnson]

On 01/16/2013 05:53 AM, Nick Clifton wrote:
> Hi Janis,
> 
>> The gcc.target/arm/ftest-*.c tests check various macros that are set for
>> ARM targets by setting flags based on preprocessor directives that check
>> those macros.  The tests are skipped if the current test platform
>> doesn't support executing programs for the architecture for which flags
>> are being checked.  There are several problems with these tests:
> 
> I like most of this patch.  The only part I am unhappy with is the new
> dg-skip-if statements to skip the test when -march or -mthumb is
> specified as part of the overall command line.  I think that the
> current dg-require-effective-target statements are enough.  Can you
> provide an example of a case where they do not work ?
> 
> Cheers
>   Nick


The "dg-require-effective-target arm_arch_v4_multilib" and friends
don't do what they're meant to do and are the reason for rewriting the
tests.

The "dg-require-effective-target arm_nothumb" isn't necessary because
thumb support is there by default it will be overridden by -marm.  If
thumb support is turned on by multilib options then it can't be
overridden, so it's necessary to look for the flag.

I've modified the tests a bit in this new version of the patch to skip
the test if the multilib includes -march with a value other than the
one being tested, rather than for _any_ use of -march.  That's necessary
because the multilib options come at the end of the command line and
override the options specified by the test.  A test looking for macros
set for -march=armv4 is going to fail if the test is compiled with
-march=armv5.

The tests are meant to check that the macros are defined for either
-mthumb or -marm and add those options explicitly.  Values for -march
that can be used with either have tests for both.  Some -march values
can be used only for -marm or -mthumb (or their defaults) and would fail
to compile if the multilib flags use the wrong one of those.

A multilib with no flags will run all of these tests.  A multilib that
uses "-march=armv8-a -mthumb" will run only the test for those options
and skip all of the others.

I don't know why some of the tests required arm_eabi, but I can't see
any reason for it being necessary for this version of the tests so I've
dropped it.

OK?

Janis
2013-01-16  Janis Johnson  

* gcc.target/arm/ftest-support.h: Replace for compile-only tests.
* gcc.target/arm/ftest-support-arm.h: Delete.
* gcc.target/arm/ftest-support-thumb.h: Delete.
* gcc.target/arm/ftest-armv4-arm.c: Replace with compile-only test.
* gcc.target/arm/ftest-armv4t-arm.c: Likewise.
* gcc.target/arm/ftest-armv4t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5t-arm.c: Likewise.
* gcc.target/arm/ftest-armv5t-thumb.c: Likewise.
* gcc.target/arm/ftest-armv5te-arm.c: Likewise.
* gcc.target/arm/ftest-armv5te-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6-arm.c: Likewise.
* gcc.target/arm/ftest-armv6-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6k-arm.c: Likewise.
* gcc.target/arm/ftest-armv6k-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6t2-arm.c: Likewise.
* gcc.target/arm/ftest-armv6t2-thumb.c: Likewise.
* gcc.target/arm/ftest-armv6z-arm.c: Likewise.
* gcc.target/arm/ftest-armv6z-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7a-arm.c: Likewise.
* gcc.target/arm/ftest-armv7a-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7em-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7m-thumb.c: Likewise.
* gcc.target/arm/ftest-armv7r-arm.c: Likewise.
* gcc.target/arm/ftest-armv7r-thumb.c: Likewise.
* gcc.target/arm/ftest-armv8a-arm.c: Likewise.
* gcc.target/arm/ftest-armv8a-thumb.c: Likewise.

Index: gcc.target/arm/ftest-support.h
===
--- gcc.target/arm/ftest-support.h  (revision 195216)
+++ gcc.target/arm/ftest-support.h  (working copy)
@@ -1,84 +1,156 @@
-#if 0
-#define INTERNAL_DEBUG 1
+/* For each of several ARM architecture features, check that relevant
+   macros are defined or not, and that they have the expected values.  */
+
+#ifdef NEED_ARM_ARCH
+# ifdef __ARM_ARCH
+#  if __ARM_ARCH != VALUE_ARM_ARCH
+#   error __ARM_ARCH has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH is not defined but should be
+# endif
+#else
+# ifdef __ARM_ARCH
+#  error __ARM_ARCH is defined but should not be
+# endif
 #endif
 
-#ifdef INTERNAL_DEBUG
-#include 
+#ifdef NEED_ARM_ARCH_ISA_ARM
+# ifdef __ARM_ARCH_ISA_ARM
+#  if __ARM_ARCH_ISA_ARM != VALUE_ARM_ARCH_ISA_ARM
+#   error __ARM_ARCH_ISA_ARM has unexpected value
+#  endif
+# else
+#  error __ARM_ARCH_ISA_ARM is not de

Re: PING: gcc.target/arm: skip 5 tests for flag conflicts

[Janis Johnson]

On 01/16/2013 05:31 AM, Nick Clifton wrote:
> Hi Janis,
> 
>> Back in September I submitted a patch to fix five ARM tests in
>>  <http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01515.html>.
>> You responded in < http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00972.html>
>> and I answered your questions in a reply.
> 
> I believe that Richard's main point was that the skips that you were
> adding to the tests meant that they would not be run for valid
> command line options.

Now I get it.  This version is more selective about which multilibs
are skipped.  I tested it by using multilib test flags for all valid 
values for -march, with and without -mthumb as appropriate for the 
arch.  The ones that are now skipped are the ones that used to fail
with complaints from the compiler.

Is this OK?

Janis
2013-01-16  Janis Johnson  

* gcc.target/arm/pr40887.c: Require at least armv5.
* gcc.target/arm/pr51835.c: Avoid conflicts with multilib flags.
* gcc.target/arm/pr51915.c: Likewise.
* gcc.target/arm/pr52006.c: Likewise.
* gcc.target/arm/pr53187.c: Likewise.

Index: src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr40887.c
===
--- src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr40887.c (revision 
195216)
+++ src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr40887.c (working copy)
@@ -1,3 +1,4 @@
+/* { dg-skip-if "need at least armv5" { *-*-* } { "-march=armv[234]*" } { "" } 
} */
 /* { dg-options "-O2 -march=armv5te" }  */
 /* { dg-final { scan-assembler "blx" } } */
 
Index: src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51835.c
===
--- src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51835.c (revision 
195216)
+++ src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51835.c (working copy)
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -mfloat-abi=hard -mfpu=fpv4-sp-d16" }  */
-/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-skip-if "no support for hard-float VFP ABI" { arm_thumb1 } { 
"-march=*" } { "" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
+/* { dg-skip-if "avoid conflicting -mfpu" { *-*-* } { "-mfpu=*" } { 
"-mfpu=fpv4-sp-d16" "-mfpu=vfpv3xd" "-mfpu=vfpv3xd-fp16" } } */
+/* { dg-options "-O2 -march=armv7-a -mfloat-abi=hard -mfpu=fpv4-sp-d16" }  */
 
 int func1 (double d)
 {
Index: src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51915.c
===
--- src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51915.c (revision 
195216)
+++ src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr51915.c (working copy)
@@ -1,5 +1,7 @@
 /* PR target/51915 */
 /* { dg-do compile } */
+/* { dg-skip-if "no support for hard-float VFP ABI" { arm_thumb1 } { 
"-march=*" } { "" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
 
 struct S { int s1; void *s2; };
Index: src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr52006.c
===
--- src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr52006.c (revision 
195216)
+++ src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr52006.c (working copy)
@@ -1,5 +1,7 @@
 /* PR target/52006 */
 /* { dg-do compile } */
+/* { dg-skip-if "avoid conflicts with multilib flags" { *-*-* } { 
"-mfloat-abi=*" } { "-mfloat-abi=hard" } } */
+/* { dg-skip-if "no support for hard-float VFP ABI" { arm_thumb1 } { 
"-march=*" } { "" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2 -fPIC" } */
 
 unsigned long a;
Index: src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr53187.c
===
--- src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr53187.c (revision 
195216)
+++ src/gcc-mainline/gcc/testsuite/gcc.target/arm/pr53187.c (working copy)
@@ -1,5 +1,7 @@
 /* PR target/53187 */
 /* { dg-do compile } */
+/* { dg-skip-if "no support for hard-float VFP ABI" { arm_thumb1 } { 
"-march=*" } { "" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
 
 void bar (int);

Re: [PATCH] [testsuite] [arm] Test thumb1 far jump

[Janis Johnson]

On 01/16/2013 06:05 PM, Joey Ye wrote:
> Test cases for previous patch "no lr save for non-far branches in leaf
> function".
> 
>   * gcc.target/arm/thumb1-far-jump-1.c: New.
>   * gcc.target/arm/thumb1-far-jump-2.c: New.
> 
> Index: gcc/testsuite/gcc.target/arm/thumb1-far-jump-2.c
> ===
> --- gcc/testsuite/gcc.target/arm/thumb1-far-jump-2.c  (revision 0)
> +++ gcc/testsuite/gcc.target/arm/thumb1-far-jump-2.c  (revision 0)
> @@ -0,0 +1,58 @@
> +/* Check for thumb1 far jump. This is the extreme case that far jump
> + * will be used with minimum number of instructions. By passing this case
> + * it means the heuristic of saving lr for far jump meets the most extreme
> + * requirement.  */
> +/* { dg-require-effective-target arm_thumb1_ok } */
> +/* { dg-options "-Os" } */
> +/* { dg-skip-if "" { ! { arm_thumb1 } } } */

The effective target arm_thumb1_ok returns 1 if it's OK to add -mthumb
to the current multilib flags and together they generate code for
Thumb-1.  arm_thumb1 says that the current multilib flags generate
code for Thumb-1.

If you want to add -mthumb to the test then use:

/* { dg-require-effective-target arm_thumb1_ok } */
/* { dg-options "-Os -mthumb" } */

Otherwise use

/* { dg-skip-if "" { ! arm_thumb1 } } */
/* { dg-options "-Os" } */

> +/* { dg-final { scan-assembler "push.*lr" } } */
> Index: gcc/testsuite/gcc.target/arm/thumb1-far-jump-1.c
> ===
> --- gcc/testsuite/gcc.target/arm/thumb1-far-jump-1.c  (revision 0)
> +++ gcc/testsuite/gcc.target/arm/thumb1-far-jump-1.c  (revision 0)
> @@ -0,0 +1,35 @@
> +/* Check for thumb1 far jump. Shouldn't save lr for small leaf functions
> + * even with a branch in it.  */
> +/* { dg-require-effective-target arm_thumb1_ok } */
> +/* { dg-options "-Os" } */
> +/* { dg-skip-if "" { ! { arm_thumb1 } } } */

Same here.

The tests are OK with those changes, but please wait a day or two
for other comments or a clear OK from an ARM maintainer.

Janis

testsuite] clean up convoluted dg-final directive in vect-multitypes-12.c

[Janis Johnson]

Test gcc.dg/vect/vect-multitypes uses Tcl conditions within a dg-final
directive, which is something that DejaGnu handles but we strive not to
do.  It's now possible to use supported constructs to get the same
result, so I've cleaned up the test and checked it in as obvious.  I'm
fixing this particular test because I want to add an xfail but want to
keep that change separate from the cleanup.

Janis
2013-01-18  Janis Johnson  

* gcc.dg/vect/vect-multitypes-12.c: Refactor dg-final directive.

Index: gcc/testsuite/gcc.dg/vect/vect-multitypes-12.c
===
--- gcc/testsuite/gcc.dg/vect/vect-multitypes-12.c  (revision 195286)
+++ gcc/testsuite/gcc.dg/vect/vect-multitypes-12.c  (working copy)
@@ -38,7 +38,9 @@
   return 0;
 }
 
+/* bleah */
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" { target 
vect_unpack } } } */
-/* { dg-final { if [ istarget sparc*-*-* ] { scan-tree-dump-times "vectorized 
1 loops" 1 "vect" { xfail ilp32 } } else { scan-tree-dump-times "vectorized 1 
loops" 1 "vect" { target { ! vect_unpack } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
sparc*-*-* xfail ilp32 } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { 
{ ! sparc*-*-* }  && { ! vect_unpack } } } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
 

backporting testsuite fixes to 4.7 branch

[Janis Johnson]

For primarily selfish reasons I'd like to backport several testsuite
fixes from mainline to the 4.7 branch.  Should I request permission for
specific groups of changes, or just do it?

Janis

Re: testsuite] clean up convoluted dg-final directive in vect-multitypes-12.c

[Janis Johnson]

On 01/23/2013 02:52 PM, Eric Botcazou wrote:
>> Test gcc.dg/vect/vect-multitypes uses Tcl conditions within a dg-final
>> directive, which is something that DejaGnu handles but we strive not to
>> do.  It's now possible to use supported constructs to get the same
>> result, so I've cleaned up the test and checked it in as obvious.  I'm
>> fixing this particular test because I want to add an xfail but want to
>> keep that change separate from the cleanup.
> 
> Something doesn't work anymore for SPARC though:
> 
> ERROR: gcc.dg/vect/vect-multitypes-12.c: error executing dg-final: bad index 
> "18-1": must be integer or end?-integer?
> UNRESOLVED: gcc.dg/vect/vect-multitypes-12.c: error executing dg-final: bad 
> index "18-1": must be integer or end?-integer?
> ERROR: gcc.dg/vect/vect-multitypes-12.c -flto: error executing dg-final: bad 
> index "18-1": must be integer or end?-integer?
> UNRESOLVED: gcc.dg/vect/vect-multitypes-12.c -flto: error executing dg-final: 
> bad index "18-1": must be integer or end?-integer?
> 

The error message comes from Tcl but I don't know what it's complaining
about and it works fine for me, even if I replace "sparc*-*-*" with
"arm*-*-*".

Would you mind playing around with it a bit, like removing the xfail from
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target 
sparc*-*-* xfail ilp32 } } } */
and removing/disabling the directives with sparc*-*-*?

I had forgotten to move the comment above the replaced convoluted
directive: "/* bleah */".  I see it's still appropriate.

Janis

Re: testsuite] clean up convoluted dg-final directive in vect-multitypes-12.c

[Janis Johnson]

On 01/23/2013 04:57 PM, Eric Botcazou wrote:
>> Would you mind playing around with it a bit, like removing the xfail from
>> /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
>> sparc*-*-* xfail ilp32 } } } */ and removing/disabling the directives with
>> sparc*-*-*?
> 
> I already played a bit when I wrote the original directive and didn't find 
> any 
> other way to do it (but my DejaGNU is admittedly quite limited).
> 

The ability to use both "target" and "xfail" in the same directive is fairly
new, but I haven't had any problems while playing around with it.  I don't
think it's used much in the test suite yet.  It's possible it's part of the
new problem you're seeing, although I don't understand how.

I modified the test because I expected to make another change to the dg-final
directives but now I don't need those changes, so if we don't figure out how
to fix it I can just revert the patch.

Janis

[testsuite] commited: fix typo in 4.7 testsuite/lib/target-supports.exp

[Janis Johnson]

This patch fixes the typo reported in PR testsuite/56206.  Checked in as
obvious.

Janis
2013-02-04  Janis Johnson  

PR testsuite/56206
* lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok):
Fix typo.

Index: testsuite/lib/target-supports.exp
===
--- testsuite/lib/target-supports.exp   (revision 195723)
+++ testsuite/lib/target-supports.exp   (working copy)
@@ -2061,7 +2061,7 @@
 # options.
 
 proc check_effective_target_arm_hard_vfp_ok { } {
-if { [check_effective_target_arm32] } {
+if { [check_effective_target_arm32]
 && ! [check-flags [list "" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" }]] } {
return [check_no_compiler_messages arm_hard_vfp_ok executable {
int main() { return 0;}

Re: [PATCH,testsuite] Added test for PR 55987

[Janis Johnson]

On 02/14/2013 10:02 AM, Tilman Sauerbeck wrote:
> Hi,
> here's a patch that adds a testcase for PR 55987.
> Is xfail the right thing to use here? I went with that since I guess the
> PR won't be fixed anytime soon ;)
> 
> I haven't assigned copyright to the FSF -- is this patch small enough to
> go in without it?
> 
> Thanks,
> Tilman

I would prefer to add the test after the bug has been fixed.
Tests for unfixed bugs clutter up the test suite.

Janis

> 2013-02-14  Tilman Sauerbeck  
> 
>   PR target/55987
>   * gcc.target/arm/pr55987.c: New.
> 
> diff --git a/gcc/testsuite/gcc.target/arm/pr55987.c 
> b/gcc/testsuite/gcc.target/arm/pr55987.c
> new file mode 100644
> index 000..7dd9de0
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pr55987.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +/* { dg-final { scan-assembler-times ".word" 1 { xfail *-*-* } } } */
> +/* { dg-final { scan-assembler "bic" { xfail *-*-* } } } */
> +
> +unsigned f(unsigned x, unsigned y)
> +{
> + unsigned c = 0x7f7f7f7f;
> +
> + return (x & c) ^ (y & ~c);
> +}
> 
> 

Re: [Patch] Cleanup gcc.target/arm/interrupt-*.c for thumb mode

[Janis Johnson]

On 02/13/2013 06:39 AM, Greta Yorsh wrote:
> The tests gcc.target/arm/interrupt-*.c are for ARM mode only. 
> This patch uses effective target arm_notthumb instead of __thumb_ predefine,
> removes unreachable code, and fixes typos.
> 
> Ok for trunk?
> 
OK

Janis

> Thanks,
> Greta
> 
> ChangeLog
> 
> gcc/testsuite/
> 
> 2012-02-13  Greta Yorsh  
> 
> * gcc.target/arm/interrupt-1.c: Fix for thumb mode.
> * gcc.target/arm/interrupt-2.c: Likewise.
> 

Re: [4.7, testsuite] Clear hwcap_2 with Sun ld

[Janis Johnson]

On 02/19/2013 05:25 AM, Rainer Orth wrote:
> I'd like to backport
> 
>   [testsuite] Clear hwcap_2 with Sun ld
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01246.html
> 
> 2012-06-19  Rainer Orth  
> 
>   * gcc.target/i386/clearcapv2.map: New file.
>   * gcc.target/i386/i386.exp: Try it first before clearcap.map.
> 
> to the 4.7 branch since recently all avx2 tests started to FAIL there on
> Solaris 10 and 11/x86 with Sun as.  It applies cleanly as is,
> bootstrapped without regressions on i386-pc-solaris2.10 and
> x86_64-unknown-linux-gnu.
> 
> Ok for 4.7 branch?
> 
>   Rainer 
> 

OK.

Janis

Re: [PATCH] Strength reduction part 3 of 4: candidates with unknown strides

[Janis Johnson]

On 08/08/2012 03:27 PM, Andrew Pinski wrote:
> On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu  wrote:
>> On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
>>  wrote:
>>> Greetings,
>>>
>>> Thanks for the review of part 2!  Here's another chunk of the SLSR code
>>> (I feel I owe you a few beers at this point).  This performs analysis
>>> and replacement on groups of related candidates having an SSA name
>>> (rather than a constant) for a stride.
>>>
>>> This leaves only the conditional increment (CAND_PHI) case, which will
>>> be handled in the last patch of the series.
>>>
>>> Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
>>> regressions.  Ok for trunk?
>>>
>>> Thanks,
>>> Bill
>>>
>>>
>>> gcc:
>>>
>>> 2012-08-01  Bill Schmidt  
>>>
>>> * gimple-ssa-strength-reduction.c (struct incr_info_d): New struct.
>>> (incr_vec): New static var.
>>> (incr_vec_len): Likewise.
>>> (address_arithmetic_p): Likewise.
>>> (stmt_cost): Remove dead assignment.
>>> (dump_incr_vec): New function.
>>> (cand_abs_increment): Likewise.
>>> (lazy_create_slsr_reg): Likewise.
>>> (incr_vec_index): Likewise.
>>> (count_candidates): Likewise.
>>> (record_increment): Likewise.
>>> (record_increments): Likewise.
>>> (unreplaced_cand_in_tree): Likewise.
>>> (optimize_cands_for_speed_p): Likewise.
>>> (lowest_cost_path): Likewise.
>>> (total_savings): Likewise.
>>> (analyze_increments): Likewise.
>>> (ncd_for_two_cands): Likewise.
>>> (nearest_common_dominator_for_cands): Likewise.
>>> (profitable_increment_p): Likewise.
>>> (insert_initializers): Likewise.
>>> (introduce_cast_before_cand): Likewise.
>>> (replace_rhs_if_not_dup): Likewise.
>>> (replace_one_candidate): Likewise.
>>> (replace_profitable_candidates): Likewise.
>>> (analyze_candidates_and_replace): Handle candidates with SSA-name
>>> strides.
>>>
>>> gcc/testsuite:
>>>
>>> 2012-08-01  Bill Schmidt  
>>>
>>> * gcc.dg/tree-ssa/slsr-5.c: New.
>>> * gcc.dg/tree-ssa/slsr-6.c: New.
>>> * gcc.dg/tree-ssa/slsr-7.c: New.
>>> * gcc.dg/tree-ssa/slsr-8.c: New.
>>> * gcc.dg/tree-ssa/slsr-9.c: New.
>>> * gcc.dg/tree-ssa/slsr-10.c: New.
>>> * gcc.dg/tree-ssa/slsr-11.c: New.
>>> * gcc.dg/tree-ssa/slsr-12.c: New.
>>> * gcc.dg/tree-ssa/slsr-13.c: New.
>>> * gcc.dg/tree-ssa/slsr-14.c: New.
>>> * gcc.dg/tree-ssa/slsr-15.c: New.
>>> * gcc.dg/tree-ssa/slsr-16.c: New.
>>> * gcc.dg/tree-ssa/slsr-17.c: New.
>>> * gcc.dg/tree-ssa/slsr-18.c: New.
>>> * gcc.dg/tree-ssa/slsr-19.c: New.
>>> * gcc.dg/tree-ssa/slsr-20.c: New.
>>> * gcc.dg/tree-ssa/slsr-21.c: New.
>>> * gcc.dg/tree-ssa/slsr-22.c: New.
>>> * gcc.dg/tree-ssa/slsr-23.c: New.
>>> * gcc.dg/tree-ssa/slsr-24.c: New.
>>> * gcc.dg/tree-ssa/slsr-25.c: New.
>>> * gcc.dg/tree-ssa/slsr-26.c: New.
>>> * gcc.dg/tree-ssa/slsr-30.c: New.
>>> * gcc.dg/tree-ssa/slsr-31.c: New.
>>>
>>>
>> ==
>>> --- gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c (revision 0)
>>> +++ gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c (revision 0)
>>> @@ -0,0 +1,25 @@
>>> +/* Verify straight-line strength reduction fails for simple integer 
>>> addition
>>> +   with casts thrown in when -fwrapv is used.  */
>>> +
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O3 -fdump-tree-dom2 -fwrapv" } */
>>> +/* { dg-skip-if "" { ilp32 } { "-m32" } { "" } } */
>>> +
>>
>> This doesn't work on x32 nor Linux/ia32 since -m32
>> may not be needed for ILP32.  This patch works for
>> me.  OK to install?
> 
> This also does not work for mips64 where the options are either
> -mabi=32 or -mabi=n32 for ILP32.
> 
> HJL's patch looks correct.
> 
> Thanks,
> Andrew

There are GCC targets with 16-bit integers.  What's the actual
set of targets on which this test is meant to run?  There's a list
of effective-target names based on data type sizes in
.

Janis

>>
>> Thanks.
>>
>>
>> --
>> H.J.
>> ---
>>* gcc.dg/tree-ssa/slsr-30.c: Require non-ilp32.  Remove
>>dg-skip-if.
>>
>> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c 
>> b/gcc/testsuite/gcc.dg/tree
>> -ssa/slsr-30.c
>> index fbd6897..7921f43 100644
>> --- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c
>> +++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c
>> @@ -1,9 +1,8 @@
>>  /* Verify straight-line strength reduction fails for simple integer addition
>> with casts thrown in when -fwrapv is used.  */
>>
>> -/* { dg-do compile } */
>> +/* { dg-do compile { target { ! { ilp32 } } } } */
>>  /* { dg-options "-O3 -fdump-tree-dom2 -fwrapv" } */
>> -/* { dg-skip-if "" { ilp32 } { "-m32" } { "" }

Re: [PATCH] Strength reduction part 3 of 4: candidates with unknown strides

[Janis Johnson]

On 08/08/2012 06:41 PM, William J. Schmidt wrote:
> On Wed, 2012-08-08 at 15:35 -0700, Janis Johnson wrote:
>> On 08/08/2012 03:27 PM, Andrew Pinski wrote:
>>> On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu  wrote:
>>>> On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
>>>>  wrote:

>>>>> +/* { dg-do compile } */
>>>>> +/* { dg-options "-O3 -fdump-tree-dom2 -fwrapv" } */
>>>>> +/* { dg-skip-if "" { ilp32 } { "-m32" } { "" } } */
>>>>> +
>>>>
>>>> This doesn't work on x32 nor Linux/ia32 since -m32
>>>> may not be needed for ILP32.  This patch works for
>>>> me.  OK to install?
>>>
>>> This also does not work for mips64 where the options are either
>>> -mabi=32 or -mabi=n32 for ILP32.
>>>
>>> HJL's patch looks correct.
>>>
>>> Thanks,
>>> Andrew
>>
>> There are GCC targets with 16-bit integers.  What's the actual
>> set of targets on which this test is meant to run?  There's a list
>> of effective-target names based on data type sizes in
>> <http://gcc.gnu.org/onlinedocs/gccint/Effective_002dTarget-Keywords.html#Effective_002dTarget-Keywords>.
> 
> Yes, sorry.  The test really is only valid when int and long have
> different sizes.  So according to that link we should skip ilp32 and
> llp64 at a minimum.  It isn't clear what we should do for int16 since
> the size of long isn't specified, so I suppose we should skip that as
> well.  So, perhaps modify HJ's patch to have
> 
> /* { dg-do compile { target { ! { ilp32 llp64 int16 } } } } */
> 
> ?
> 
> Thanks,
> Bill

That's confusing.  Perhaps what you really need is a new effective
target for "sizeof(int) != sizeof(long)".

Janis

Re: [PATCH, testsuite] New effective target long_neq_int

[Janis Johnson]

On 08/09/2012 06:46 PM, William J. Schmidt wrote:
> As suggested by Janis regarding testsuite/gcc.dg/tree-ssa/slsr-30.c,
> this patch adds a new effective target for machines having long and int
> of differing sizes.
> 
> Tested on powerpc64-unknown-linux-gnu, where the test passes for -m64
> and is skipped for -m32.  Ok for trunk?

OK!

Janis

> Thanks,
> Bill
> 
> 
> doc:
> 
> 2012-08-09  Bill Schmidt  
> 
>   * sourcebuild.texi: Document long_neq_int effective target.
> 
> 
> testsuite:
> 
> 2012-08-09  Bill Schmidt  
> 
>   * lib/target-supports.exp (check_effective_target_long_neq_int): New.
>   * gcc.dg/tree-ssa/slsr-30.c: Check for long_neq_int effective target.
> 
> 
> Index: gcc/doc/sourcebuild.texi
> ===
> --- gcc/doc/sourcebuild.texi  (revision 190260)
> +++ gcc/doc/sourcebuild.texi  (working copy)
> @@ -1303,6 +1303,9 @@ Target has @code{int} that is at 32 bits or longer
>  @item int16
>  Target has @code{int} that is 16 bits or shorter.
>  
> +@item long_neq_int
> +Target has @code{int} and @code{long} with different sizes.
> +
>  @item large_double
>  Target supports @code{double} that is longer than @code{float}.
>  
> Index: gcc/testsuite/lib/target-supports.exp
> ===
> --- gcc/testsuite/lib/target-supports.exp (revision 190260)
> +++ gcc/testsuite/lib/target-supports.exp (working copy)
> @@ -1689,6 +1689,15 @@ proc check_effective_target_llp64 { } {
>  }]
>  }
>  
> +# Return 1 if long and int have different sizes,
> +# 0 otherwise.
> +
> +proc check_effective_target_long_neq_int { } {
> +return [check_no_compiler_messages long_ne_int object {
> + int dummy[sizeof (int) != sizeof (long) ? 1 : -1];
> +}]
> +}
> +
>  # Return 1 if the target supports long double larger than double,
>  # 0 otherwise.
>  
> Index: gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c
> ===
> --- gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c   (revision 190260)
> +++ gcc/testsuite/gcc.dg/tree-ssa/slsr-30.c   (working copy)
> @@ -1,7 +1,7 @@
>  /* Verify straight-line strength reduction fails for simple integer addition
> with casts thrown in when -fwrapv is used.  */
>  
> -/* { dg-do compile { target { ! { ilp32 } } } } */
> +/* { dg-do compile { target { long_neq_int } } } */
>  /* { dg-options "-O3 -fdump-tree-dom2 -fwrapv" } */
>  
>  long
> 
> 

Re: [PATCH, testsuite] No short enum in tree-ssa test

[Janis Johnson]

On 08/23/2012 08:05 PM, Joey Ye wrote:
> Ssa-dom-thread-3.c has following code to trigger a warning on ARM. Add
> -fno-short-enums to suppress it.
> struct tree_base
> {
>   enum tree_code code:16;
> };
> 
> OK to trunk and 4.7?

OK.

Janis

> 2012-08-15  Joey Ye 
> 
> * gcc.dg/tree-ssa/ssa-dom-thread-3.c: Add -fno-short-enums.
> 
> Index: testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c
> ===
> --- testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c  (revision 190337)
> +++ testsuite/gcc.dg/tree-ssa/ssa-dom-thread-3.c  (working copy)
> @@ -1,5 +1,5 @@
>  /* { dg-do compile } */ 
> -/* { dg-options "-O2 -fdump-tree-dom1-details" } */
> +/* { dg-options "-O2 -fdump-tree-dom1-details -fno-short-enums" } */
> extern void abort (void) __attribute__ ((__noreturn__));
>  union tree_node;
>  typedef union tree_node *tree;
> 
> 
> 
> 
> 
> 
> 

Re: [PATCH, ARM] Constant vector permute for the Neon vext insn

[Janis Johnson]

On 08/27/2012 08:02 AM, Christophe Lyon wrote:
> [ Richard, sorry for the duplicate message where I omitted the mailing-list]
> 
> On 24 August 2012 10:40, Richard Earnshaw  wrote:
>>
>> Has this been tested for big-endian?
>>
> 
> Hi,
> While improving my tests and trying to turn them into execution tests,
> I realized that vector initialization such as:
>   uint16x4_t vec1 = {0x1234, 0x5678, 0x9abc, 0xdef0};
> is endianness dependent.
> 
> However, I have noticed that other tests (such as neon-vrev.c,
> neon-vset_lanes8.c, pr48252) do use such constructs and the last
> two ones fail at execution in big-endian mode (the 1st one is only
> compiled).
> 
> I guess that the 'right' (portable) was of initializing a vector is to
> load it from an array, right?

See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01114.html for Richard
Earnshaw's suggestion on how to fix neon-vset_lanes8.c, and an alternate
suggestion for changing the compiler.

Janis

Re: [Patch ARM testsuite] fix 3 tests for big-endian

[Janis Johnson]

On 08/31/2012 05:05 AM, Christophe Lyon wrote:
> Hi,
> 
> Tests gcc.target/arm/pr48252.c, gcc.target/arm/pr51835.c  and
> gcc.target/arm/neon-vset_lanes8.c currently expect little-endian code
> and fail when compiled/executed in big-endian mode.
> 
> The attached patch fixes them.
> 
> Tested with qemu on armeb-none-linux-gnueabi and arm-none-linux-gnueabi.
> 
> OK?

I'll let an ARM expert review the patch, but please don't use TCL
code in test directives.  Instead of

+/* { dg-final { if [check_effective_target_arm_little_endian] \{ } } */
 /* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t 
\]*d0" 2 } } */
+/* { dg-final { \}   else \{ } } */
+/* { dg-final {scan-assembler-times "fmrrd\[\\t \]+r1,\[\\t \]*r0,\[\\t 
\]*d0" 2  } } */
+/* { dg-final { \}

do something like

/* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r0,\[\\t \]*r1,\[\\t \]*d0" 
2 } { target arm_little_endian } } */
/* { dg-final { scan-assembler-times "fmrrd\[\\t \]+r1,\[\\t \]*r0,\[\\t \]*d0" 
2  } {target { ! arm_little_endian } } } */

That's untested, but you get the idea.

Janis

testsuite] remove dg-do run from a vect test

[Janis Johnson]

The infrastructure for gcc.dg/vect tests determines whether the default
is for tests to be compile-only or compile plus execute.  Tests that
should not be executed use { dg-do compile }, but no test should use
{ dg-do run }.  This patch removes { dg-do run} from pr52298.c.

Tested on arm-none-eabi for default and big-endian, checked in on trunk
as obvious.  I'll backport to 4.6 when the branch is open.

Janis
2012-09-18  Janis Johnson  

* gcc.dg/vect/pr52298.c: Remove "dg-do run".

Index: gcc.dg/vect/pr52298.c
===
--- gcc.dg/vect/pr52298.c   (revision 191440)
+++ gcc.dg/vect/pr52298.c   (working copy)
@@ -1,4 +1,3 @@
-/* { dg-do run } */
 /* { dg-options "-O1 -ftree-vectorize -fno-tree-pre -fno-tree-loop-im" } */
 
 extern void abort (void);

[testsuite] vect effective targets should use arm_neon_ok

[Janis Johnson]

In most cases a test that requires ARM NEON should use effective target
arm_neon, which means that flags run for all tests include NEON support.
The result is cached the first time it is checked for a multilib.

Vectorization tests, when run for ARM, add flags to support NEON if it's
OK to do so, but those flags are not reflected in the cached results for
arm_neon, nor should they be.  Because of this, vect effective-target
checks should use arm_neon_ok (as most already do) instead of arm_neon.

This patch changes the checks for 7 effective targets, allowing more
tests to run and decreasing the number of failures.  The only new
failures I've seen in tests on arm-none-eabi with a variety of test
multilibs are for big-endian with vect_multiple_sizes, which means
that vect_multiple_sizes should be false for big endian or that there's
a bug in ARM big-endian support.

Checked in on trunk as obvious.  I'll backport to 4.6 when it's open.

Janis
2012-09-18  Janis Johnson  

* lib/target-supports.exp
(check_effective_target_vect_widen_mult_qi_to_hi,
check_effective_target_vect_widen_mult_hi_to_si,
check_effective_target_vect_widen_mult_qi_to_hi_pattern,
check_effective_target_vect_widen_mult_hi_to_si_pattern,
check_effective_target_vect_pack_trunc,
check_effective_target_vect_unpack,
check_effective_target_vect_multiple_sizes): Check arm_neon_ok
instead of arm_none.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 191440)
+++ lib/target-supports.exp (working copy)
@@ -3097,7 +3097,7 @@
set et_vect_widen_mult_qi_to_hi_saved 0
}
 if { [istarget powerpc*-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
 set et_vect_widen_mult_qi_to_hi_saved 1
 }
 }
@@ -3131,7 +3131,7 @@
  || [istarget ia64-*-*]
  || [istarget i?86-*-*]
  || [istarget x86_64-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
 set et_vect_widen_mult_hi_to_si_saved 1
 }
 }
@@ -3152,7 +3152,7 @@
 } else {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 0
 if { [istarget powerpc*-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
 set et_vect_widen_mult_qi_to_hi_pattern_saved 1
 }
 }
@@ -3177,7 +3177,7 @@
   || [istarget ia64-*-*]
   || [istarget i?86-*-*]
   || [istarget x86_64-*-*]
-  || ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+  || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) 
} {
 set et_vect_widen_mult_hi_to_si_pattern_saved 1
 }
 }
@@ -3307,7 +3307,7 @@
  || [istarget i?86-*-*]
  || [istarget x86_64-*-*]
  || [istarget spu-*-*]
- || ([istarget arm*-*-*] && [check_effective_target_arm_neon]
+ || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]
 && [check_effective_target_arm_little_endian]) } {
 set et_vect_pack_trunc_saved 1
 }
@@ -,7 +,7 @@
  || [istarget x86_64-*-*] 
  || [istarget spu-*-*]
  || [istarget ia64-*-*]
- || ([istarget arm*-*-*] && [check_effective_target_arm_neon]
+ || ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]
 && [check_effective_target_arm_little_endian]) } {
 set et_vect_unpack_saved 1
 }
@@ -3751,7 +3751,7 @@
 global et_vect_multiple_sizes_saved
 
 set et_vect_multiple_sizes_saved 0
-if { ([istarget arm*-*-*] && [check_effective_target_arm_neon]) } {
+if { ([istarget arm*-*-*] && [check_effective_target_arm_neon_ok]) } {
set et_vect_multiple_sizes_saved 1
 }
 if { ([istarget x86_64-*-*] || [istarget i?86-*-*]) } {

[testsuite] for vect_multiple_sizes, skip instead of xfail for some checks

[Janis Johnson]

Seventeen tests in gcc.dg/vect that use vect_multiple_sizes have checks
similar to:

/* { dg-final { scan-tree-dump-times "can't determine dependence" 2 "vect" { 
xfail vect_multiple_sizes } } } */
/* { dg-final { scan-tree-dump-times "can't determine dependence" 4 "vect" { 
target vect_multiple_sizes } } } *

When vect_multiple_sizes is true the first check shouldn't be reported
as XFAIL, it should intead be skipped.  The convention in other vect
tests is to instead use:

/* { dg-final { scan-tree-dump-times "can't determine dependence" 2 "vect" { 
target { ! vect_multiple_sizes } } } } */
/* { dg-final { scan-tree-dump-times "can't determine dependence" 4 "vect" { 
target vect_multiple_sizes } } } *

This patch fixes those 17 tests.  Tested on arm-none-eabi with a variety
of test multilibs, checked in on trunk as obvious.  I'll backport to 4.6
when the branch is open.

Janis
2012-09-18  Janis Johnson  

* gcc.dg/vect/no-vfa-vect-101.c: Skip a check for an irrelevant
target instead of xfailing it.
* gcc.dg/vect/no-vfa-vect-102.c: Likewise.
* gcc.dg/vect/no-vfa-vect-102a.c: Likewise.
* gcc.dg/vect/no-vfa-vect-37.c: Likewise.
* gcc.dg/vect/no-vfa-vect-79.c: Likewise.
* gcc.dg/vect/vect-104.c: Likewise.
* gcc.dg/vect/vect-outer-1-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-1.c: Likewise.
* gcc.dg/vect/vect-outer-1a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-1a.c: Likewise.
* gcc.dg/vect/vect-outer-1b-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-1b.c: Likewise.
* gcc.dg/vect/vect-outer-2b.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-3b.c: Likewise.
* gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise.

Index: gcc.dg/vect/no-vfa-vect-101.c
===
--- gcc.dg/vect/no-vfa-vect-101.c   (revision 191440)
+++ gcc.dg/vect/no-vfa-vect-101.c   (working copy)
@@ -45,7 +45,7 @@
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */
-/* { dg-final { scan-tree-dump-times "can't determine dependence" 1 "vect" { 
xfail vect_multiple_sizes } } } */
+/* { dg-final { scan-tree-dump-times "can't determine dependence" 1 "vect" { 
target { ! vect_multiple_sizes } } } } */
 /* { dg-final { scan-tree-dump-times "can't determine dependence" 2 "vect" { 
target vect_multiple_sizes } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
 
Index: gcc.dg/vect/no-vfa-vect-102.c
===
--- gcc.dg/vect/no-vfa-vect-102.c   (revision 191440)
+++ gcc.dg/vect/no-vfa-vect-102.c   (working copy)
@@ -53,7 +53,7 @@
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */
-/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1 
"vect" { xfail vect_multiple_sizes } } } */
+/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1 
"vect" { target { ! vect_multiple_sizes } } } } */
 /* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 2 
"vect" { target vect_multiple_sizes } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
 
Index: gcc.dg/vect/no-vfa-vect-102a.c
===
--- gcc.dg/vect/no-vfa-vect-102a.c  (revision 191440)
+++ gcc.dg/vect/no-vfa-vect-102a.c  (working copy)
@@ -53,7 +53,7 @@
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */
-/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1 
"vect" { xfail vect_multiple_sizes } } } */
+/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1 
"vect" { target { ! vect_multiple_sizes } } } } */
 /* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 2 
"vect" { target vect_multiple_sizes } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
 
Index: gcc.dg/vect/no-vfa-vect-37.c
===
--- gcc.dg/vect/no-vfa-vect-37.c(revision 191440)
+++ gcc.dg/vect/no-vfa-vect-37.c(working copy)
@@ -58,6 +58,6 @@
If/when the aliasing problems are resolved, unalignment may
prevent vectorization on some targets.  */
 /* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { xfail 
*-*-* } } } */
-/* { dg-final { sc

[testsuite] vect/fast-math-pr35982: skip check instead of xfail

[Janis Johnson]

Test gcc.dg/vect/fast-math-pr35982.c uses xfail in a dg-final check when
it should instead skip the check for that effective target.  Tested on
arm-none-eabi for a variety of test multilibs, checked in on trunk as
obvious.  I'll backport to 4.6 when the branch is open.

Janis
2012-09-18  Janis Johnson  

* gcc.dg/vect/fast-math-pr35982.c: Skip check instead of xfail.

Index: gcc.dg/vect/fast-math-pr35982.c
===
--- gcc.dg/vect/fast-math-pr35982.c (revision 191440)
+++ gcc.dg/vect/fast-math-pr35982.c (working copy)
@@ -21,5 +21,5 @@
 }
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { 
vect_extract_even_odd || vect_strided2 } } } } */
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { xfail { 
vect_extract_even_odd || vect_strided2 } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target { 
! { vect_extract_even_odd || vect_strided2 } } } } } */
 /* { dg-final { cleanup-tree-dump "vect" } } */

Re: [testsuite] vect effective targets should use arm_neon_ok

[Janis Johnson]

On 09/18/2012 12:54 PM, Janis Johnson wrote:
> In most cases a test that requires ARM NEON should use effective target
> arm_neon, which means that flags run for all tests include NEON support.
> The result is cached the first time it is checked for a multilib.
> 
> Vectorization tests, when run for ARM, add flags to support NEON if it's
> OK to do so, but those flags are not reflected in the cached results for
> arm_neon, nor should they be.  Because of this, vect effective-target
> checks should use arm_neon_ok (as most already do) instead of arm_neon.
> 
> This patch changes the checks for 7 effective targets, allowing more
> tests to run and decreasing the number of failures.  The only new
> failures I've seen in tests on arm-none-eabi with a variety of test
> multilibs are for big-endian with vect_multiple_sizes, which means
> that vect_multiple_sizes should be false for big endian or that there's
> a bug in ARM big-endian support.

Oops, I got that wrong.  There are other effective-targets that might
need arm_little_endian, but not vect_multiple_sizes.  I'll file a PR
when I have better information.

> Checked in on trunk as obvious.  I'll backport to 4.6 when it's open.
> 
> Janis

[testsuite] gcc.dg/vect/pr48765: fix option conflict

[Janis Johnson]

Test gcc.dg/vect/pr48765, run only for powerpc*-*-*, unconditionally
adds -mcpu=power6 to the command line.  It also adds -m64, although
tests should rely on different multilib flags for that and skip the
test if not lp64 if the test can only be run with -m64.

For all of the Power multilib flags that I normally test, the vect test
infrastructure either skips the tests (for E500) or adds "-maltivec
-mcpu=970" which conflicts with the "-mcpu=power6" in this test and
causes the test to fail to compile.

The "-m64" definitely has to go.  If the "-mcpu=power6" needs to stay in
order to use the flags that triggered the ICE for which the test was
added, then the test should be skipped if some other -mcpu option will
override it.  Another option is to remove that and figure that
occasionally someone will run tests for power6.

This version keeps "-mcpu=power6" and skips the tests if another -mcpu
is already specified.  OK for trunk, and for 4.7 when the branch opens?

Janis
2012-09-18  Janis Johnson  

* gcc.dg/vect/pr48765.c: Skip for conflicting options, don't
specify -m64.

Index: gcc.dg/vect/pr48765.c
===
--- gcc.dg/vect/pr48765.c   (revision 386848)
+++ gcc.dg/vect/pr48765.c   (working copy)
@@ -1,5 +1,6 @@
-/* { dg-do compile { target powerpc*-*-* } } */
-/* { dg-options "-m64 -O3 -mcpu=power6" } */
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { 
"-mcpu=power6" } } */
+/* { dg-options "-O3 -mcpu=power6" } */
 
 enum reg_class
 {

Re: [testsuite] support using "target" and "xfail" together

[Janis Johnson]

Ping.

On 07/24/2012 11:13 AM, Janis Johnson wrote:
> This patch allows the use of both "target" and "xfail" in the selector
> of any test directive that currently takes either "target" or "xfail":
> 
>   { target selector1 xfail selector2 }
> 
> The test is only used if the "target" selector is matched, and the test
> is expected to fail if the "xfail" selector is matched.  The keyword
> "target" must come first; it doesn't make sense to me otherwise because
> the xfail part shouldn't be processed if the target selector doesn't
> match.
> 
> Tested with i686-pc-linux-gnu for c,c++,gfortran,objc,obj-c++ plus with
> examples using the new feature, with and without errors.
> 
> I'd like some feedback before checking this in so I'll wait at least a
> couple of days.  I plan to put it on the 4.7 branch also.

I'd still like some feedback; I guess I lied when I said I'd check it
in anyway.

Janis

Re: [testsuite] support using "target" and "xfail" together

[Janis Johnson]

On 09/19/2012 10:48 AM, Mike Stump wrote:
> On Sep 19, 2012, at 10:35 AM, Janis Johnson  wrote:
>> On 07/24/2012 11:13 AM, Janis Johnson wrote:
>>> This patch allows the use of both "target" and "xfail" in the selector
>>> of any test directive that currently takes either "target" or "xfail":
>>>
>>>  { target selector1 xfail selector2 }
>>>
>>> The test is only used if the "target" selector is matched, and the test
>>> is expected to fail if the "xfail" selector is matched.  The keyword
>>> "target" must come first; it doesn't make sense to me otherwise because
>>> the xfail part shouldn't be processed if the target selector doesn't
>>> match.
>>>
>>> Tested with i686-pc-linux-gnu for c,c++,gfortran,objc,obj-c++ plus with
>>> examples using the new feature, with and without errors.
>>>
>>> I'd like some feedback before checking this in so I'll wait at least a
>>> couple of days.  I plan to put it on the 4.7 branch also.
>>
>> I'd still like some feedback; I guess I lied when I said I'd check it
>> in anyway.
> 
> I like it.  What's not to like?

All right then, I'll check it in on trunk, and on 4.7 when it's open.
Thanks!

Janis

Re: [testsuite] vect effective targets should use arm_neon_ok

[Janis Johnson]

On 09/19/2012 01:43 AM, Richard Earnshaw wrote:
> On 18/09/12 21:59, Janis Johnson wrote:
>> On 09/18/2012 12:54 PM, Janis Johnson wrote:
>>> In most cases a test that requires ARM NEON should use effective target
>>> arm_neon, which means that flags run for all tests include NEON support.
>>> The result is cached the first time it is checked for a multilib.
>>>
>>> Vectorization tests, when run for ARM, add flags to support NEON if it's
>>> OK to do so, but those flags are not reflected in the cached results for
>>> arm_neon, nor should they be.  Because of this, vect effective-target
>>> checks should use arm_neon_ok (as most already do) instead of arm_neon.
>>>
>>> This patch changes the checks for 7 effective targets, allowing more
>>> tests to run and decreasing the number of failures.  The only new
>>> failures I've seen in tests on arm-none-eabi with a variety of test
>>> multilibs are for big-endian with vect_multiple_sizes, which means
>>> that vect_multiple_sizes should be false for big endian or that there's
>>> a bug in ARM big-endian support.
>>
> 
> Sadly, there are almost certainly bugs in the big-endian support for ARM
> Neon.

I filed PR testsuite/54622 with a list of the vect tests failures for
ARM big-endian.  There aren't really issues with vect_multiple_sizes,
but there are some vect effective targets for which ARM big-endian
fails all tests.  I had originally thought the problems were with the
tests; apparently not.

Janis

[testsuite] gcc.target/arm: skip 5 tests for flag conflicts

[Janis Johnson]

This patch adds test directives to skip 5 tests in gcc.target/arm if the
flags specified for the test would be overridden by or conflict with
flags used for all tests, such as multilib flags.

Tested on arm-none-eabi with a variety of test flags.  I'll wait a day
or two before checking it in to give ARM experts a chance to comment.
I plan to backport to the 4.7 branch soon after it's in trunk.

Janis
2012-09-20  Janis Johnson  

* gcc.target/arm/pr40887.c: Avoid conflicting flags.
* gcc.target/arm/pr51835.c: Likewise.
* gcc.target/arm/pr51915.c: Likewise.
* gcc.target/arm/pr52006.c: Likewise.
* gcc.target/arm/pr53187.c: Likewise.

Index: gcc.target/arm/pr40887.c
===
--- gcc.target/arm/pr40887.c(revision 191502)
+++ gcc.target/arm/pr40887.c(working copy)
@@ -1,3 +1,4 @@
+/* { dg-skip-if " do not override -march" { *-*-* } { "-march=*" } { 
"-march=armv5te" } } */
 /* { dg-options "-O2 -march=armv5te" }  */
 /* { dg-final { scan-assembler "blx" } } */

Index: gcc.target/arm/pr51835.c
===
--- gcc.target/arm/pr51835.c(revision 191502)
+++ gcc.target/arm/pr51835.c(working copy)
@@ -1,6 +1,8 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
+/* { dg-skip-if "do not override -mfpu" { *-*-* } { "-mfpu=*" } { 
"-mfpu=fpv4-sp-d16" } } */
 /* { dg-options "-O2 -mfloat-abi=hard -mfpu=fpv4-sp-d16" }  */
-/* { dg-require-effective-target arm_thumb2_ok } */
 
 int func1 (double d)
 {
Index: gcc.target/arm/pr51915.c
===
--- gcc.target/arm/pr51915.c(revision 191502)
+++ gcc.target/arm/pr51915.c(working copy)
@@ -1,5 +1,7 @@
 /* PR target/51915 */
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -march" { *-*-* } { "-march=*" } { 
"-march=armv7-a" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
 
 struct S { int s1; void *s2; };
Index: gcc.target/arm/pr52006.c
===
--- gcc.target/arm/pr52006.c(revision 191502)
+++ gcc.target/arm/pr52006.c(working copy)
@@ -1,5 +1,7 @@
 /* PR target/52006 */
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -march=" { *-*-* } { "-march=*" } { 
"-march=armv7-a" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2 -fPIC" } */
 
 unsigned long a;
Index: gcc.target/arm/pr53187.c
===
--- gcc.target/arm/pr53187.c(revision 191502)
+++ gcc.target/arm/pr53187.c(working copy)
@@ -1,5 +1,6 @@
 /* PR target/53187 */
 /* { dg-do compile } */
+/* { dg-skip-if "do not override -march" { *-*-* } { "-march=*" } { 
"-march=armv7-a" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -O2" } */
 
 void bar (int);

[testsuite] fix to check_effective_target_arm_hard_vfp_ok

[Janis Johnson]

Tests in gcc.target/arm/aapcs check for floating-point arguments being
passed correctly, but the added flag "-mfloat-abi=hard" can be
overridden by another value in flags used for all tests (like multilib
flags), causing the tests to fail.  The tests in that directory are all
gated on effective-target arm_hard_vfp_ok; this patch changes its code
to return 0 if the test will use a different value of -mfloat-abi.

Tested on arm-none-eabi with a variety of test flags.  I'm hoping to
hear from ARM experts that this is OK; there are a handful of tests in
arm/aapcs that pass even with -mfloat-abi=softfp, so a better solution
might be to skip individual tests for that option.

Janis
2012-09-20  Janis Johnson  

* lib/target-supports.exp (check_effective_target_arm_hard_vfp_ok):
Return 0 if already specifying -mfloat-abi other than hard.

Index: lib/target-supports.exp
===
--- lib/target-supports.exp (revision 191501)
+++ lib/target-supports.exp (working copy)
@@ -2053,7 +2053,8 @@
 # options.
 
 proc check_effective_target_arm_hard_vfp_ok { } {
-if { [check_effective_target_arm32] } {
+if { [check_effective_target_arm32] 
+&& ! [check-flags [list "" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=hard" }]] } {
return [check_no_compiler_messages arm_hard_vfp_ok executable {
int main() { return 0;}
} "-mfpu=vfp -mfloat-abi=hard"]

Re: [patch testsuite]: Fix failing test for llp64 in gcc.dg/tree-ssa

[Janis Johnson]

On 09/19/2012 10:19 AM, Kai Tietz wrote:
> Hi,
> 
> this patch fixes testsuite-failures for llp64 targets in
> gcc.dg/tree-ssa testsuite.
> 
> ChangeLog
> 
> 2012-09-19  Kai Tietz
> 
> * gcc.dg/tree-ssa/scev-3.c: Add llp64 to xfail.
> * gcc.dg/tree-ssa/scev-4.c: Likewise.
> 
> Ok for apply?

OK.

Janis

> Regards,
> Kai
> 
> Index: scev-3.c
> ===
> --- scev-3.c(Revision 191443)
> +++ scev-3.c(Arbeitskopie)
> @@ -14,5 +14,5 @@
>  }
>  }
> 
> -/* { dg-final { scan-tree-dump-times "&a" 1 "optimized" { xfail lp64 } } } */
> +/* { dg-final { scan-tree-dump-times "&a" 1 "optimized" { xfail {
> lp64 || llp64 } } } } */
>  /* { dg-final { cleanup-tree-dump "optimized" } } */
> Index: scev-4.c
> ===
> --- scev-4.c(Revision 191443)
> +++ scev-4.c(Arbeitskopie)
> @@ -19,5 +19,5 @@
>  }
>  }
> 
> -/* { dg-final { scan-tree-dump-times "&a" 1 "optimized" { xfail lp64 } } } */
> +/* { dg-final { scan-tree-dump-times "&a" 1 "optimized" { xfail {
> lp64 || llp64 } } } } */
>  /* { dg-final { cleanup-tree-dump "optimized" } } */
> 

Re: [PATCH, ARM] Fix PR44557 (Thumb-1 ICE)

[Janis Johnson]

On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:

+/* { dg-do compile } */
+/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer 
-fno-forward-propagate" }  */
+/* { dg-require-effective-target arm_thumb1_ok } */

This test will fail to compile for test flags that conflict with
the -march option, and the specified -march option might be
overridden with similar options from other test flags.  The problem
might have also been seen for other -march options.  I recommend
leaving it off and omitting the dg-require so the test can be run
for more multilibs.

Janis

[testsuite] gcc.target/arm/unsigned-extend-1.c: omit -march option

[Janis Johnson]

Test gcc.target/arm/unsigned-extend-1.c specifies option -march=armv6,
which causes compile failures when that option conflicts with other
test flags, such as for multilibs.  It can also be overridden by other
test flags.  The test is scanning that instruction "uxtb" is not
issued.  Leaving off the option won't hurt when the effective target
doesn't support the instruction, and will allow the test to be tried
with other newer processors as well.

OK for trunk?

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/unsigned-extend-1.c: Omit -march option.

Index: gcc.target/arm/unsigned-extend-1.c
===
--- gcc.target/arm/unsigned-extend-1.c  (revision 191765)
+++ gcc.target/arm/unsigned-extend-1.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -march=armv6" } */
+/* { dg-options "-O2" } */
 
 unsigned char foo (unsigned char c)
 {

[testsuite] gcc.target/arm/pr42879.c: handle big-endian

[Janis Johnson]

Test gcc.target/arm/pr42879.c fails for big-endian multilibs.  Julian
Brown suggested this fix.

Tested on arm-none-eabi with several multilibs, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/pr42879.c: Handle big-endian.

Index: gcc.target/arm/pr42879.c
===
--- gcc.target/arm/pr42879.c(revision 191765)
+++ gcc.target/arm/pr42879.c(working copy)
@@ -4,6 +4,9 @@
 
 struct A
 {
+#ifdef __ARMEB__
+  int dummy:31;
+#endif
   int v:1;
 };
 

[testsuite] gcc.target/arm/combine-movs.c: fix effective target

[Janis Johnson]

Test gcc.target/arm/combine-movs.c uses the wrong effective-target
keyword on dg-final scans; arm_thumb2_ok says that the target will
support THUMB2 if -mthumb is specified, and arm_thumb2 says that
with the current options it is supported.

Tested on arm-none-eabi with multiple flags, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/combine-movs.c: Use effective target arm_thumb2.

Index: gcc.target/arm/combine-movs.c
===
--- gcc.target/arm/combine-movs.c   (revision 191765)
+++ gcc.target/arm/combine-movs.c   (working copy)
@@ -9,5 +9,5 @@
 r[i] = 0;
 }
 
-/* { dg-final { scan-assembler "lsrs\tr\[0-9\]" { target arm_thumb2_ok } } } */
-/* { dg-final { scan-assembler "movs\tr\[0-9\]" { target { ! arm_thumb2_ok} } 
} } */
+/* { dg-final { scan-assembler "lsrs\tr\[0-9\]" { target arm_thumb2 } } } */
+/* { dg-final { scan-assembler "movs\tr\[0-9\]" { target { ! arm_thumb2 } } } 
} */

[testsuite] gcc.target/arm/mmx-2.c: specify -mcpu=iwmmxt

[Janis Johnson]

Test gcc.target/arm/mmx-2.c tests ARM iWMMXt functionality but fails to
compile if the compiler under test does not support that by default.
This patch adds -mcpu=iwmmxt.  Now instead of failing to compile due to
unrecognized builtins, it fails with the ICE described in PR54338.

Tested on arm-none-eabi for multiple flags, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/mmx-2.c: Specify -mcpu=iwmmxt.

Index: gcc.target/arm/mmx-2.c
===
--- gcc.target/arm/mmx-2.c  (revision 191765)
+++ gcc.target/arm/mmx-2.c  (working copy)
@@ -5,7 +5,7 @@
 /* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { "" 
} } */
 /* { dg-require-effective-target arm32 } */
 /* { dg-require-effective-target arm_iwmmxt_ok } */
-/* { dg-options "-flax-vector-conversions -std=gnu99" } */
+/* { dg-options "-mcpu=iwmmxt -flax-vector-conversions -std=gnu99" } */
 
 /* Internal data types for implementing the intrinsics.  */
 typedef int __v2si __attribute__ ((vector_size (8)));

[testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux

[Janis Johnson]

Test gcc.target/arm/div64-unwinding.c is known to fail for GNU/Linux 
targets, as described in PR54732.  This patch adds an XFAIL.

Tested on arm-none-eabi and arm-none-linux-gnueabi, checked in on trunk.

Janis
2012-09-26  Janis Johnson  

* gcc.target/arm/div64-unwinding.c: XFAIL for GNU/Linux.

Index: gcc.target/arm/div64-unwinding.c
===
--- gcc.target/arm/div64-unwinding.c(revision 191765)
+++ gcc.target/arm/div64-unwinding.c(working copy)
@@ -1,6 +1,7 @@
 /* Performing a 64-bit division should not pull in the unwinder.  */
 
-/* { dg-do run } */
+/* The test is expected to fail for GNU/Linux; see PR54723.  */
+/* { dg-do run { xfail *-*-linux* } } */
 /* { dg-options "-O0" } */
 
 #include 

[testsuite] more gcc.dg tests: add comments to dg-error and friends

[Janis Johnson]

This patch modifies miscellaneous tests in gcc/testsuite/gcc.dg to
specify comments in dg-message/dg-warning/dg-error test directives for
checks for multiple messages for the same line of source code.

Tested on i686-pc-linux-gnu.  OK for mainline?

Janis
2012-06-13  Janis Johnson  

* gcc.dg/di-longlong64-sync-1.c: Add comments to checks for multiple
messages reported for one line of source code.
* gcc.dg/format/few-1.c: Likewise.
* gcc.dg/ia64-sync-2.c: Likewise.
* gcc.dg/sync-2.c: Likewise.
* gcc.dg/noncompile/pr44517.c: Likewise.
* gcc.dg/noncompile/pr52290.c: Likewise.

Index: gcc.dg/di-longlong64-sync-1.c
===
--- gcc.dg/di-longlong64-sync-1.c   (revision 188482)
+++ gcc.dg/di-longlong64-sync-1.c   (working copy)
@@ -3,8 +3,8 @@
 /* { dg-options "-std=gnu99" } */
 /* { dg-additional-options "-march=pentium" { target { { i?86-*-* x86_64-*-* } 
&& ia32 } } } */
 
-/* { dg-message "note: '__sync_fetch_and_nand' changed semantics in GCC 4.4" 
"" { target *-*-* } 0 } */
-/* { dg-message "note: '__sync_nand_and_fetch' changed semantics in GCC 4.4" 
"" { target *-*-* } 0 } */
+/* { dg-message "note: '__sync_fetch_and_nand' changed semantics in GCC 4.4" 
"fetch_and_nand" { target *-*-* } 0 } */
+/* { dg-message "note: '__sync_nand_and_fetch' changed semantics in GCC 4.4" 
"nand_and_fetch" { target *-*-* } 0 } */
 
 
 /* Test basic functionality of the intrinsics.  The operations should
Index: gcc.dg/format/few-1.c
===
--- gcc.dg/format/few-1.c   (revision 188482)
+++ gcc.dg/format/few-1.c   (working copy)
@@ -4,15 +4,15 @@
 int f(int *ip, char *cp)
 {
__builtin_printf ("%*.*s");
-/* { dg-warning "field width specifier '\\*' expects a matching 'int' 
argument" "" { target *-*-* } 6 } */
-/* { dg-warning "field precision specifier '\\.\\*' expects a matching 'int' 
argument" "" { target *-*-* } 6 } */
-/* { dg-warning "format '%s' expects a matching 'char \\*' argument" "" { 
target *-*-* } 6 } */
+/* { dg-warning "field width specifier '\\*' expects a matching 'int' 
argument" "width" { target *-*-* } 6 } */
+/* { dg-warning "field precision specifier '\\.\\*' expects a matching 'int' 
argument" "precision" { target *-*-* } 6 } */
+/* { dg-warning "format '%s' expects a matching 'char \\*' argument" "format" 
{ target *-*-* } 6 } */
__builtin_printf ("%*.*s", ip, *cp);
-/* { dg-warning "field width specifier '\\*' expects argument of type 'int'" 
"" { target *-*-* } 10 } */
-/* { dg-warning "format '%s' expects a matching 'char \\*' argument" "" { 
target *-*-* } 10 } */
+/* { dg-warning "field width specifier '\\*' expects argument of type 'int'" 
"width" { target *-*-* } 10 } */
+/* { dg-warning "format '%s' expects a matching 'char \\*' argument" "format" 
{ target *-*-* } 10 } */
__builtin_printf ("%s %i", ip, ip);
-/* { dg-warning "format '%s' expects argument of type 'char \\*'" "" { target 
*-*-* } 13 } */
-/* { dg-warning "format '%i' expects argument of type 'int'" "" { target *-*-* 
} 13 } */
+/* { dg-warning "format '%s' expects argument of type 'char \\*'" "char" { 
target *-*-* } 13 } */
+/* { dg-warning "format '%i' expects argument of type 'int'" "int" { target 
*-*-* } 13 } */
__builtin_printf ("%s %i", cp);
 /* { dg-warning "format '%i' expects a matching 'int' argument" "" { target 
*-*-* } 16 } */
__builtin_printf ("%lc");
Index: gcc.dg/ia64-sync-2.c
===
--- gcc.dg/ia64-sync-2.c(revision 188482)
+++ gcc.dg/ia64-sync-2.c(working copy)
@@ -4,8 +4,8 @@
 /* { dg-options "-march=i486" { target { { i?86-*-* x86_64-*-* } && ia32 } } } 
*/
 /* { dg-options "-mcpu=v9" { target sparc*-*-* } } */
 
-/* { dg-message "note: '__sync_fetch_and_nand' changed semantics in GCC 4.4" 
"" { target *-*-* } 0 } */
-/* { dg-message "note: '__sync_nand_and_fetch' changed semantics in GCC 4.4" 
"" { target *-*-* } 0 } */
+/* { 

[testsuite] scandump.exp: use printable version of regexp

[Janis Johnson]

Most scan-* procedures used in dg-final test directives use a printable
version of the regular expression in the test summary.  This patch makes
scan-*-dump-tiles do that as well, which eliminates several duplicates
in test summaries for expressions that contain a newline.

Tested on i686-pc-linux-gnu and arm-none-eabi.  OK for mainline?

Janis
2012-06-13  Janis Johnson  

* lib/scandump.exp (scan-dump-times): Use printable version of
regexp in test summary line.

Index: lib/scandump.exp
===
--- lib/scandump.exp(revision 188482)
+++ lib/scandump.exp(working copy)
@@ -94,7 +94,8 @@
 upvar 3 name testcase
 
 set suf [dump-suffix [lindex $args 3]]
-set testname "$testcase scan-[lindex $args 0]-dump-times $suf \"[lindex 
$args 1]\" [lindex $args 2]"
+set printable_pattern [make_pattern_printable [lindex $args 1]]
+set testname "$testcase scan-[lindex $args 0]-dump-times $suf 
\"$printable_pattern\" [lindex $args 2]"
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob -nocomplain $src.[lindex $args 3]]"
 if { $output_file == "" } {

[testsuite] scanasm: don't strip torture args from testname in summary

[Janis Johnson]

Test results in a summary file usually include the torture options used
for the test run, but those options are stripped for pass/fail reports
for most scan-* procedures used in dg-final test directives.  This patch
refrains from stripping them and adds an extra space beteween those
options and the rest of the summary line to make it slightly more
readable. 

Tested on i686-pc-linux-gnu and arm-none-eabi.  OK for mainline?

Janis
2012-06-13  Janis Johnson  

* lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden,
scan-not-hiddent, scan-file, scan-file-not, scan-stack-usage,
scan-stack-usage-not): Don't strip torture options from test name.

Index: lib/scanasm.exp
===
--- lib/scanasm.exp (revision 188482)
+++ lib/scanasm.exp (working copy)
@@ -79,9 +79,10 @@
 
 proc scan-assembler { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].s"
-
 dg-scan "scan-assembler" 1 $testcase $output_file $args
 }
 
@@ -95,7 +96,9 @@
 
 proc scan-assembler-not { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].s"
 
 dg-scan "scan-assembler-not" 0 $testcase $output_file $args
@@ -126,7 +129,9 @@
 
 proc scan-hidden { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].s"
 
 set symbol [lindex $args 0]
@@ -143,7 +148,9 @@
 
 proc scan-not-hidden { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].s"
 
 set symbol [lindex $args 0]
@@ -158,7 +165,9 @@
 
 proc scan-file { output_file args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 dg-scan "scan-file" 1 $testcase $output_file $args
 }
 
@@ -167,7 +176,9 @@
 
 proc scan-file-not { output_file args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 dg-scan "scan-file-not" 0 $testcase $output_file $args
 }
 
@@ -176,7 +187,9 @@
 
 proc scan-stack-usage { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].su"
 
 dg-scan "scan-file" 1 $testcase $output_file $args
@@ -187,7 +200,9 @@
 
 proc scan-stack-usage-not { args } {
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set output_file "[file rootname [file tail $testcase]].su"
 
 dg-scan "scan-file-not" 0 $testcase $output_file $args
@@ -216,7 +231,9 @@
 # it still stores the filename of the testcase in a local variable "name".
 # A cleaner solution would require a new dejagnu release.
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 
 set pattern [lindex $args 0]
 set pp_pattern [make_pattern_printable $pattern]
@@ -276,7 +293,9 @@
 }
 
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set pattern [lindex $args 0]
 set pp_pattern [make_pattern_printable $pattern]
 set output_file "[file rootname [file tail $testcase]].s"
@@ -331,7 +350,9 @@
 }
 
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 set pattern [lindex $args 0]
 set pp_pattern [make_pattern_printable $pattern]
 set output_file "[file rootname [file tail $testcase]].s"
@@ -387,7 +408,9 @@
 }
 
 upvar 2 name testcase
-set testcase [lindex $testcase 0]
+if { [llength $testcase] > 1 } {
+   set testcase "$testcase "
+}
 
 set what [lindex $args 0]
 set where [lsearch { text data bss total } $what]

[testsuite] lib/dg-pch.exp: distinguish between two compilations in summary

[Janis Johnson]

PCH test infrastructure compiles each test twice, with identical results
in the test summary file (assuming they both pass or both fail).  This
patch adds an extra flag to each compile, "-Dcompile1" or "-Dcompile2",
to make the summary lines unique.  This is a rather lame fix but at
least I added a comment.

Tested on i686-pc-linux-gnu and arm-none-eabi.  OK for mainline?

Janis
2012-06-13  Janis Johnson  

* lib/dg-pch.exp (dg-flags-pch): Add flags to make compile lines in
test summary unique.

Index: lib/dg-pch.exp
===
--- lib/dg-pch.exp  (revision 188482)
+++ lib/dg-pch.exp  (working copy)
@@ -50,14 +50,16 @@
# Ensure that the PCH file is used, not the original header.
file_on_host delete "$bname$suffix"
 
-   dg-test -keep-output $test "$otherflags $flags -I." ""
+   # The flags "-Dcompile1" and "-Dcompile2" are to distinguish the
+   # two compiles in test summary lines.
+   dg-test -keep-output $test "$otherflags $flags -I. -Dcompile1" ""
file_on_host delete "$bname$suffix.gch"
if { !$have_errs } {
if { [ file_on_host exists "$bname.s" ] } {
remote_upload host "$bname.s" "$bname.s-gch"
remote_download host "$bname.s-gch"
gcc_copy_files "[file rootname $test]${suffix}s" 
"$bname$suffix"
-   dg-test -keep-output $test "$otherflags $flags -I." ""
+   dg-test -keep-output $test "$otherflags $flags -I. 
-Dcompile2" ""
remote_upload host "$bname.s"
set tmp [ diff "$bname.s" "$bname.s-gch" ]
if { $tmp == 0 } {
@@ -89,4 +91,4 @@
 
 proc dg-pch { subdir test options suffix } {
   return [dg-flags-pch $subdir $test "" $options $suffix]
-}
\ No newline at end of file
+}

Re: [testsuite] lib/dg-pch.exp: distinguish between two compilations in summary

[Janis Johnson]

On 06/13/2012 02:37 PM, Joseph S. Myers wrote:
> On Wed, 13 Jun 2012, Janis Johnson wrote:
> 
>> PCH test infrastructure compiles each test twice, with identical results
>> in the test summary file (assuming they both pass or both fail).  This
>> patch adds an extra flag to each compile, "-Dcompile1" or "-Dcompile2",
>> to make the summary lines unique.  This is a rather lame fix but at
>> least I added a comment.
> 
> I would have said this was bug 20771, except that you committed a fix for 
> that in 2008, so either it's a reappearance or the reason you didn't close 
> the bug in 2008 was that your fix was known incomplete.  Anyway, check for 
> open "testsuite" bugs for the issues you are fixing.
> 

The patch for PR20771 did fix the problem (so I should have closed it)
but it was undone as part of a later change to the same lines.  I could
either do that again, with comments this time explaining why they are
slightly different, or use "-Dwith_PCH" and "-Dwithout_PCH" in the flags
that will appear in the test summary.  Do you have a preference?

Janis

[testsuite] g++.dg, g++.old-deja: unique lines for messages in test summary

[Janis Johnson]

This test modifies dg-message, dg-warning, and dg-error test directives
for several G++ tests by adding comments that will be added to lines in
the test summary to eliminate non-unique lines for checks of messages
for the same line of source code in a test.

Tested on i686-pc-linux-gnu and arm-none-eabi, checked in.

Janis
2012-06-15  Janis Johnson  

* g++.dg/cpp0x/auto27.C: Add comments to checks for multiple
messages reported for one line of source code.
* g++.dg/cpp0x/constexpr-decl.C: Likewise.
* g++.dg/cpp0x/decltype2.C: Likewise.
* g++.dg/cpp0x/decltype3.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-syntax1.C: Likewise.
* g++.dg/cpp0x/regress/error-recovery1.C: Likewise.
* g++.dg/cpp0x/static_assert3.C: Likewise.
* g++.dg/cpp0x/udlit-cpp98-neg.C: Likewise.
* g++.dg/cpp0x/udlit-shadow-neg.C: Likewise.
* g++.dg/cpp0x/union1.C: Likewise.
* g++.dg/cpp0x/variadic-ex10.C: Likewise.
* g++.dg/cpp0x/variadic-ex14.C: Likewise.
* g++.dg/cpp0x/variadic2.C: Likewise.
* g++.dg/cpp0x/variadic20.C: Likewise.
* g++.dg/cpp0x/variadic74.C: Likewise.
* g++.dg/diagnostic/bitfld2.C: Likewise.
* g++.dg/ext/attrib44.C: Likewise.
* g++.dg/ext/no-asm-1.C: Likewise.
* g++.dg/other/error34.C: Likewise.
* g++.dg/parse/crash46.C: Likewise.
* g++.dg/parse/error10.C: Likewise.
* g++.dg/parse/error2.C: Likewise.
* g++.dg/parse/error3.C: Likewise.
* g++.dg/parse/error36.C: Likewise.
* g++.dg/parse/error8.C: Likewise.
* g++.dg/parse/error9.C: Likewise.
* g++.dg/parse/parser-pr28152-2.C: Likewise.
* g++.dg/parse/parser-pr28152.C: Likewise.
* g++.dg/parse/template25.C: Likewise.
* g++.dg/parse/typename11.C: Likewise.
* g++.dg/tc1/dr147.C: Likewise.
* g++.dg/template/deduce3.C: Likewise.
* g++.dg/template/koenig9.C: Likewise.
* g++.dg/template/pr23510.C: Likewise.
* g++.dg/warn/pr12242.C: Likewise.
* g++.dg/warn/pr30551-2.C: Likewise.
* g++.dg/warn/pr30551.C: Likewise.
* g++.old-deja/g++.other/typename1.C: Likewise.
* g++.old-deja/g++.pt/niklas01a.C: Likewise.

Index: g++.dg/cpp0x/auto27.C
===
--- g++.dg/cpp0x/auto27.C   (revision 188540)
+++ g++.dg/cpp0x/auto27.C   (working copy)
@@ -1,6 +1,6 @@
 // PR c++/51186
 
-auto main()->int  // { dg-error "std=" "" { target c++98 } }
-  // { dg-error "auto" "" { target c++98 } 3 }
-  // { dg-error "no type" "" { target c++98 } 3 }
+auto main()->int  // { dg-error "std=" "std" { target c++98 } }
+  // { dg-error "auto" "auto" { target c++98 } 3 }
+  // { dg-error "no type" "no type" { target c++98 
} 3 }
 { }
Index: g++.dg/cpp0x/constexpr-decl.C
===
--- g++.dg/cpp0x/constexpr-decl.C   (revision 188540)
+++ g++.dg/cpp0x/constexpr-decl.C   (working copy)
@@ -2,8 +2,8 @@
 // { dg-options -std=c++0x }
 
 struct S {
-  static constexpr int size;   // { dg-error "must have an initializer" }
-  // { dg-error "previous declaration" "" { target *-*-* } 5 }
+  static constexpr int size;   // { dg-error "must have an initializer" "must 
have" }
+  // { dg-error "previous declaration" "previous" { target *-*-* } 5 }
 };
 
 const int limit = 2 * S::size;
Index: g++.dg/cpp0x/decltype2.C
===
--- g++.dg/cpp0x/decltype2.C(revision 188540)
+++ g++.dg/cpp0x/decltype2.C(working copy)
@@ -45,8 +45,8 @@
 int bar(int); 
 CHECK_DECLTYPE(decltype(foo), int(char));
 
-decltype(bar) z; // { dg-error "overload" }
-// { dg-error "invalid type" "" { target *-*-* } 48 }
+decltype(bar) z; // { dg-error "overload" "overload" }
+// { dg-error "invalid type" "invalid" { target *-*-* } 48 }
 
 CHECK_DECLTYPE(decltype(&foo), int(*)(char));
 CHECK_DECLTYPE(decltype(*&foo), int(&)(char));
Index: g++.dg/cpp0x/decltype3.C
===
--- g++.dg/cpp0x/decltype3.C(revision 188540)
+++ g++.dg/cpp0x/decltype3.C(working copy)
@@ -55,8 +55,8 @@
 }; 
 
 CHECK_DECLTYPE(decltype(aa.*&A::a), int&);
-decltype(aa.*&A::b) zz; // { dg-error "cannot create pointer to reference 
member" }
-// { dg-error "invalid type" "" { target *-*-* } 58 }
+decltype(aa.*&A::b) zz; // { dg-error "cannot create pointer to re

[testsuite] g++.dg/torture/stackalign: make compile lines unique in test summary

[Janis Johnson]

Like the C stackalign tests, the tests in g++.dg/torture/stackalign use
two sets of torture options: the usual optimization sets used as default
for torture tests, and sets of options that are specific to stack
alignment.  There are fewer stack alignment options used for the G++
tests but otherwise the setup is the same.

This patch is similar to the one for the C stackalign tests and uses
existing support to combine the torture options and stackalign options
so they are all reported in the pass/fail lines in the test summary to
make each line unique.  Since this isn't significantly different from
the patch for C tests I'm not waiting for a review.

Tested on i686-pc-linux-gnu and arm-none-eabi, checked in.

Janis
2012-06-15  Janis Johnson  

* g++.dg/torture/stackalign/stackalign.exp: Combine stack
alignment torture options with usual torture options.

Index: g++.dg/torture/stackalign/stackalign.exp
===
--- g++.dg/torture/stackalign/stackalign.exp(revision 188540)
+++ g++.dg/torture/stackalign/stackalign.exp(working copy)
@@ -1,4 +1,4 @@
-# Copyright (C) 2008, 2010
+# Copyright (C) 2008, 2010, 2012
 # Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
@@ -18,18 +18,41 @@
 # This harness is for tests that should be run at all optimisation levels.
 
 load_lib g++-dg.exp
+load_lib torture-options.exp
+
+global DG_TORTURE_OPTIONS LTO_TORTURE_OPTIONS
+
 dg-init
-set additional_flags ""
+torture-init
 
+# default_flags are replaced by a dg-options test directive, or appended
+# to by using dg-additional-options.  Use default_flags for options that
+# are used in all of the torture sets to limit the amount of noise in
+# test summaries.
+set default_flags ""
+
+# torture_flags are combined with other torture options and do not
+# affect options specified within a test.
+set torture_flags ""
+
+set stackalign_options [list]
+
 # If automatic stack alignment is supported, force it on.
 if { [check_effective_target_automatic_stack_alignment] } then {
-lappend additional_flags "-mstackrealign"
-lappend additional_flags "-mpreferred-stack-boundary=5"
+append default_flags " -mstackrealign"
+append default_flags " -mpreferred-stack-boundary=5"
 }
+lappend stackalign_options [join $torture_flags]
 
-gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.C]] $additional_flags
 if { [check_effective_target_fpic] } then {
-lappend additional_flags "-fpic"
-gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.C]] $additional_flags
+lappend torture_flags "-fpic"
+lappend stackalign_options [join $torture_flags]
 }
+
+# Combine stackalign options with the usual torture optimization flags.
+set-torture-options [concat $DG_TORTURE_OPTIONS $LTO_TORTURE_OPTIONS] 
$stackalign_options
+
+gcc-dg-runtest [lsort [glob $srcdir/$subdir/*.C]] "$default_flags"
+
+torture-finish
 dg-finish

[testsuite] gcov.exp: include flags in test summary lines

[Janis Johnson]

GCOV tests for C++ are run for both std=gnu++98 and std=gnu++11.  Those
options are not reported by GCOV-specific lines in the test summary,
leading to non-unique lines.  This patch modifies the GCOV test support
to use a testname that includes the extra flags used for a set of tests
and also modifies the format of summary lines to better incorporate that
information.  For example, these lines:

  PASS: gcc.misc-tests/gcov-1.c:17 line count
  PASS: gcc.misc-tests/gcov-1.c gcov

  PASS: g++.dg/gcov/gcov-1.C:279 line count
  PASS: g++.dg/gcov/gcov-1.C gcov

are now:

  PASS: gcc.misc-tests/gcov-1.c count for line 17
  PASS: gcc.misc-tests/gcov-1.c gcov

  PASS: g++.dg/gcov/gcov-1.C -std=gnu++98 count for line 279
  PASS: g++.dg/gcov/gcov-1.C -std=gnu++98 gcov
  PASS: g++.dg/gcov/gcov-1.C -std=gnu++11 count for line 279
  PASS: g++.dg/gcov/gcov-1.C -std=gnu++11 gcov

Tested on i686-pc-linux-gnu and arm-eabi for gcc and g++ GCOV tests.
OK for mainline?

Janis
2012-06-15  Janis Johnson  

* lib/gcov.exp (verify-lines, verify-branches, verify-calls): Use
testname that includes flags, passed in as new argument, in
pass/fail messages.
(run_gcov): Get testname from dg-test, use it in pass/fail messages
and pass it to verify-* procedures.

Index: lib/gcov.exp
===
--- lib/gcov.exp(revision 188622)
+++ lib/gcov.exp(working copy)
@@ -34,12 +34,14 @@
 #
 # verify-lines -- check that line counts are as expected
 #
-# TESTCASE is the name of the test.
+# TESTNAME is the name of the test, including unique flags.
+# TESTCASE is the name of the test file.
 # FILE is the name of the gcov output file.
 #
-proc verify-lines { testcase file } {
+proc verify-lines { testname testcase file } {
 #send_user "verify-lines\n"
 global subdir
+
 set failed 0
 set fd [open $file r]
 while { [gets $fd line] >= 0 } {
@@ -54,13 +56,13 @@
}
}
if { $is == "" } {
-   fail "$subdir/$testcase:$n:no data available for this line"
+   fail "$testname line $n: no data available"
incr failed
} elseif { $is != $shouldbe } {
-   fail "$subdir/$testcase:$n:is $is:should be $shouldbe"
+   fail "$testname line $n: is $is:should be $shouldbe"
incr failed
} else {
-   pass "$subdir/$testcase:$n line count"
+   pass "$testname count for line $n"
}
}
 }
@@ -71,7 +73,8 @@
 #
 # verify-branches -- check that branch percentages are as expected
 #
-# TESTCASE is the name of the test.
+# TESTNAME is the name of the test, including unique flags.
+# TESTCASE is the name of the test file.
 # FILE is the name of the gcov output file.
 #
 # Checks are based on comments in the source file.  This means to look for
@@ -86,8 +89,9 @@
 # branch instructions.  Don't check for branches that might be
 # optimized away or replaced with predicated instructions.
 #
-proc verify-branches { testcase file } {
+proc verify-branches { testname testcase file } {
 #send_user "verify-branches\n"
+
 set failed 0
 set shouldbe ""
 set fd [open $file r]
@@ -99,7 +103,7 @@
if [regexp "branch\\((\[0-9 \]+)\\)" "$line" all new_shouldbe] {
# All percentages in the current list should have been seen.
if {[llength $shouldbe] != 0} {
-   fail "$n: expected branch percentages not found: $shouldbe"
+   fail "$testname line $n: expected branch percentages not 
found: $shouldbe"
incr failed
set shouldbe ""
}
@@ -117,14 +121,14 @@
} elseif [regexp "branch +\[0-9\]+ taken (-\[0-9\]+)%" "$line" \
all taken] {
# Percentages should never be negative.
-   fail "$n: negative percentage: $taken"
+   fail "$testname line $n: negative percentage: $taken"
incr failed
} elseif [regexp "branch +\[0-9\]+ taken (\[0-9\]+)%" "$line" \
all taken] {
#send_user "$n: taken = $taken\n"
# Percentages should never be greater than 100.
if {$taken > 100} {
-   fail "$n: percentage greater than 100: $taken"
+   fail "$testname line $n: branch percentage greater than 
100: $taken"
incr failed
}
if {$taken > 50} {
@@ -139,7 +143,7 @@
} elseif [regexp "branch\\(end\\)" "$line"] {
# All p

Re: [testsuite] gcov.exp: include flags in test summary lines

[Janis Johnson]

On 06/15/2012 12:32 PM, Mike Stump wrote:
> On Jun 15, 2012, at 11:07 AM, Janis Johnson wrote:
>> GCOV tests for C++ are run for both std=gnu++98 and std=gnu++11.  Those
>> options are not reported by GCOV-specific lines in the test summary,
> 
>> OK for mainline?
> 
> Ok.
> 
> It is scary that upvar is ever used

Yes, it is.  I've sometimes thought that for testname it might be
just a little less scary to use a proc like current_compiler_flags
in target-supports-dg.exp, instead of using upvar in every single
place we need access to that particular variable from dg-test.

Janis

Re: [PATCH, testsuite]: Fix scan-tree-dump-times argument order in gcc.dg/tree-ssa/vrp68.c.

[Janis Johnson]

On 06/17/2012 05:03 AM, Richard Guenther wrote:
> On Sun, Jun 17, 2012 at 10:41 AM, Uros Bizjak  wrote:
>> Hello!
>>
>> The testcase still fails on x86_64-pc-linux-gnu with:
>>
>> FAIL: gcc.dg/tree-ssa/vrp68.c scan-tree-dump-times vrp1 "link_error" 1
>>
>> since there are two calls to link_error.
> 
> Oops.  I wonder how I did not see those failures myself ...
> 
> Richard.

I'm confused about what this test is supposed to do.  It uses
"dg-do link" which means the compile (test for excess errors) will
fail if there is a reference to link_error.  There are two uses of
scan-tree-dump-times for the same string in the same file, so one
of those is guaranteed to fail.  It looks like the scans aren't
needed, and "dg-do link" is the thing that needs the xfail.

Janis

[testsuite] profopt.exp and friends: use expected list of options

[Janis Johnson]

There are tests in g++.tree-prof that have non-unique lines in test
summaries for scan-*-dump checks.  Investigation showed that these tests
were being run multiple times, for a list of options that had leaked
over from another set of profile-directed optimization tests.  This
patch doesn't fix duplicate lines for checks in profiled tests that are
run multiple times, but it does avoid the problem and, in so doing, fix
tests that use profopt.exp so they are run with the correct sets of
options.

Without this patch, tests in g++.dg/tree-prof are run with
[ { -g } { -O0 } { -O1 } { -O2 } { -O3 } { -O3 -g } { -Os } ] instead
of the expected [list {}].  Each test provides its own options, so
the ones from PROFOPT_OPTIONS were ignored.

Tests gcc.misc-tests/bprob*.c were supposed to be run with a set of
options that was instead overridden by an empty list.  This patch makes
it use [ { -O2 } {-O3 } ] so the options tested there will get some
coverage with optimization, although not as much as originally planned
when the tests were added years and years ago.

The other sets of tests that use profopt.exp continue to be tested with
the same options they've been using.

OK for mainline?

Janis
2012-06-18  Janis Johnson  

* lib/profopt.exp: Make prof_option_list local to profopt-execute.
* g++.dg/tree-prof/tree-prof.exp (PROFOPT_OPTIONS): Define after
including profopt.opt; save and restore existing value.
* g++.dg/bprob/bprob.exp: Likewise.
* gcc.dg/matrix/matrix.exp: Likewise.
* gcc.dg/tree-prof/tree-prof.exp: Likewise.
* gcc.misc-tests/bprob.exp: Likewise; also replace formerly-ignored
PROFOPT_OPTIONS.

Index: lib/profopt.exp
===
--- lib/profopt.exp (revision 188753)
+++ lib/profopt.exp (working copy)
@@ -64,8 +64,6 @@
{ -Os } ]
 }
 
-set prof_option_list $PROFOPT_OPTIONS
-
 #
 # profopt-cleanup -- remove profiling or performance results files.
 #
@@ -215,7 +213,7 @@
 #
 proc profopt-execute { src } {
 global srcdir tmpdir
-global prof_option_list
+global PROFOPT_OPTIONS
 global tool profile_option feedback_option prof_ext perf_ext perf_delta
 global generate_final_code use_final_code
 global verbose
@@ -227,6 +225,12 @@
 error "No feedback option specified for second compile."
 }
 
+# Use the default option list or one defined for a set of tests.
+if ![info exists PROFOPT_OPTIONS] {
+ error "PROFOPT_OPTIONS is not defined"
+}
+set prof_option_list $PROFOPT_OPTIONS
+
 regsub "(?q)$srcdir/" $src "" testcase
 # If we couldn't rip $srcdir out of `src' then just do the best we can.
 # The point is to reduce the unnecessary noise in the logs.  Don't strip
Index: g++.dg/tree-prof/tree-prof.exp
===
--- g++.dg/tree-prof/tree-prof.exp  (revision 188753)
+++ g++.dg/tree-prof/tree-prof.exp  (working copy)
@@ -29,9 +29,6 @@
 set tool g++
 set prof_ext "gcda"
 
-# Override the list defined in profopt.exp.
-set PROFOPT_OPTIONS [list {}]
-
 if $tracelevel then {
 strace $tracelevel
 }
@@ -39,6 +36,10 @@
 # Load support procs.
 load_lib profopt.exp
 
+# Save and override the default list defined in profopt.exp.
+set treeprof_save_profopt_options $PROFOPT_OPTIONS
+set PROFOPT_OPTIONS [list {}]
+
 # These are globals used by profopt-execute.  The first is options
 # needed to generate profile data, the second is options to use the
 # profile data.
@@ -52,3 +53,5 @@
 }
 profopt-execute $src
 }
+
+set PROFOPT_OPTIONS $treeprof_save_profopt_options
Index: g++.dg/bprob/bprob.exp
===
--- g++.dg/bprob/bprob.exp  (revision 188753)
+++ g++.dg/bprob/bprob.exp  (working copy)
@@ -33,7 +33,11 @@
 strace $tracelevel
 }
 
-# Override the list defined in profopt.exp.
+# Load support procs.
+load_lib profopt.exp
+
+# Save and override the default list defined in profopt.exp.
+set bprob_save_profopt_options $PROFOPT_OPTIONS
 set PROFOPT_OPTIONS [list \
{ -g } \
{ -O0 } \
@@ -47,9 +51,6 @@
 strace $tracelevel
 }
 
-# Load support procs.
-load_lib profopt.exp
-
 set profile_options "-fprofile-arcs"
 set feedback_options "-fbranch-probabilities"
 
@@ -63,3 +64,5 @@
 profopt-execute $src
 }
 }
+
+set PROFOPT_OPTIONS $bprob_save_profopt_options
Index: gcc.dg/matrix/matrix.exp
===
--- gcc.dg/matrix/matrix.exp(revision 188753)
+++ gcc.dg/matrix/matrix.exp(working copy)
@@ -39,9 +39,6 @@
 set tool gcc
 set prof_ext "gcda"
 
-# Override the list defined in profopt.exp.
-set PROFOPT_OPTIONS [list {}]
-
 if $tracelevel then {
 strace $tracelevel
 }
@@ -49,6 +46,10 @@
 # Load 

[testsuite] access name from dg-test via a proc instead of upvar

[Janis Johnson]

Lots of places in GCC's testsuite infrastructure get the test name with
current torture options, set up by DejaGnu's dg-test, by using upvar.
These accesses usually have a comment that this is ugly but there's
nothing else to do.  I recently modified that test name for use by the
scan directives to add an extra space, not realizing that I was changing
the actual variable from dg-test, so tests that use a lot of scans are
getting one more space per scan message.  Checking for options in the
name and adding a space also slowed things down quite a bit.

This patch limits the use of upvar for "name" in dg-test to a new proc
which saves its value for further uses in the same test, with an extra
space at the end if there are torture options.

Tested on i686-pc-linux-gnu for gcc and g++.  OK for trunk?

Janis
2012-06-25  Janis Johnson  

* lib/target-supports-dg.exp (testname-for-summary): New.
* lib/profopt.exp (profopt_execute): Define testname_with_flags.
* lib/gcc-dg.exp (cleanup-coverage-files, cleanup-repo-notes,
cleanup-stack-usage, cleanup-dump, cleanup-saved-temps, scan-module,
scan-module-absence, output-exists, output-exists-not: Use
testname-for-summary.
(dg-test): Clean up testname_with_flags.
* lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden,
scan-not-hidden, scan-file, scan-file-not, scan-stack-usage,
scan-stack-usage-not, scan-assembler-times, scan-assembler-dem,
scan-assembler-dem-not, object-size: Use testname-for-summary.
* lib/gcov.exp (run-gcov): Likewise.
* lib/scandump.exp (scan-dump, scan-dump-times, scan-dump-not,
scan-dump-dem, scan-dump-dem-note): Likewise.

Index: lib/target-supports-dg.exp
===
--- lib/target-supports-dg.exp  (revision 188964)
+++ lib/target-supports-dg.exp  (working copy)
@@ -31,6 +31,34 @@
 return "$flags1 $flags2"
 }
 
+# DejaGnu's dg-test defines a test name that includes torture options
+# which is used in most pass/fail messages.  Grab a copy of it.
+
+proc testname-for-summary { } {
+global testname_with_flags
+
+# A variable called "name" is too generic, so identify dg-test by
+# the existence of dg-extra-tool-flags.
+if ![info exists testname_with_flags] {
+   set frames 2
+   while { ![info exists flags] } {
+   set frames [expr $frames + 1]
+   upvar $frames dg-extra-tool-flags flags
+   }
+
+   # We've got the stack level for dg-test; get the variable we want.
+   upvar $frames name name
+   set testname_with_flags $name
+
+   # If there are flags, add an extra space to improve readability of
+   # the test summary.
+   if { [llength $testname_with_flags] > 1 } {
+   set testname_with_flags "$testname_with_flags "
+   }
+}
+return "$testname_with_flags"
+}
+
 # If this target does not support weak symbols, skip this test.
 
 proc dg-require-weak { args } {
Index: lib/profopt.exp
===
--- lib/profopt.exp (revision 188964)
+++ lib/profopt.exp (working copy)
@@ -217,6 +217,7 @@
 global tool profile_option feedback_option prof_ext perf_ext perf_delta
 global generate_final_code use_final_code
 global verbose
+global testname_with_flags
 
 if ![info exists profile_option] {
 error "No profile option specified for first compile."
@@ -240,6 +241,12 @@
set testcase "[file tail [file dirname $src]]/[file tail $src]"
 }
 
+# Several procedures access the name of the test with torture flags,
+# normally defined in dg-test.  Profile optimization tests don't
+# use dg-test, so define it here to make it accessible via
+# testname-for-summary.
+set testname_with_flags $testcase
+
 set executable $tmpdir/[file tail [file rootname $src].x]
 set basename [file tail $testcase]
 set base [file rootname $basename]
@@ -272,6 +279,7 @@
set extra_flags [profopt-get-options $src]
if { [lindex ${dg-do-what} 1 ] == "N" } {
unsupported "$src"
+   unset testname_with_flags
verbose "$src not supported on this target, skipping it" 3
return
}
@@ -437,4 +445,5 @@
remote_file build delete $execname3
}
 }
+unset testname_with_flags
 }
Index: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp  (revision 188964)
+++ lib/gcc-dg.exp  (working copy)
@@ -433,10 +433,7 @@
 
 # Remove compiler-generated coverage files for the current test.
 proc cleanup-coverage-files { } {
-# This assumes that we are two frames down from dg-test or some other proc
-# that stores the filename of the te

[testsuite] scandump.exp: use printable pattern in test summary

[Janis Johnson]

Procedure scan-dump-times in scandump.exp uses a printable version of
the scanned pattern in the line reported to the test summary but others
in that file don't.  This patch fixes that in the remaining procedures
in scandump.exp.  The primary advantage of using the printable pattern
is with patterns that include newlines, to keep the pattern all on the
same line in the test summary.

Tested on i686-pc-linux-gnu for gcc and g++.  OK for trunk?

Janis
2012-06-26  Janis Johnson  

* lib/scandump.exp (scan-dump, scan-dump-not, scan-dump-dem,
scan-dump-dem-not): Use printable pattern in test name.

Index: lib/scandump.exp
===
--- lib/scandump.exp(revision 188974)
+++ lib/scandump.exp(working copy)
@@ -47,8 +47,9 @@
 
 set testcase [testname-for-summary]
 
+set printable_pattern [make_pattern_printable [lindex $args 1]]
 set suf [dump-suffix [lindex $args 2]]
-set testname "$testcase scan-[lindex $args 0]-dump $suf \"[lindex $args 
1]\""
+set testname "$testcase scan-[lindex $args 0]-dump $suf 
\"$printable_pattern\""
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob -nocomplain $src.[lindex $args 2]]"
 if { $output_file == "" } {
@@ -126,8 +127,9 @@
 }
 
 set testcase [testname-for-summary]
+set printable_pattern [make_pattern_printable [lindex $args 1]]
 set suf [dump-suffix [lindex $args 2]]
-set testname "$testcase scan-[lindex $args 0]-dump-not $suf \"[lindex 
$args 1]\""
+set testname "$testcase scan-[lindex $args 0]-dump-not $suf 
\"$printable_pattern\""
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob -nocomplain $src.[lindex $args 2]]"
 if { $output_file == "" } {
@@ -178,8 +180,9 @@
 }
 
 set testcase [testname-for-summary]
+set printable_pattern [make_pattern_printable [lindex $args 1]]
 set suf [dump-suffix [lindex $args 2]]
-set testname "$testcase scan-[lindex $args 0]-dump-dem $suf \"[lindex 
$args 1]\""
+set testname "$testcase scan-[lindex $args 0]-dump-dem $suf 
\"$printable_pattern\""
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob -nocomplain $src.[lindex $args 2]]"
 if { $output_file == "" } {
@@ -229,8 +232,9 @@
 }
 
 set testcase [testname-for-summary]
+set printable_pattern [make_pattern_printable [lindex $args 1]
 set suf [dump-suffix [lindex $args 2]]
-set testname "$testcase scan-[lindex $args 0]-dump-dem-not $suf \"[lindex 
$args 1]\""
+set testname "$testcase scan-[lindex $args 0]-dump-dem-not $suf 
\"$printable_pattern\""
 set src [file tail [lindex $testcase 0]]
 set output_file "[glob -nocomplain $src.[lindex $args 2]]"
 if { $output_file == "" } {

[testsuite] gcc.dg/vect/vect-50.c: combine two scans

[Janis Johnson]

These scans from gcc.dg/vect/vect-50.c, and others similar to them in
other vect tests, hurt my brain:

/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" 
{ xfail { vect_no_align } } } }  */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" 
{ target vect_hw_misalign } } } */

Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the
gcc test summary.  I'm pretty sure the following accomplishes the same
goal:

/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 "vect" 
{ xfail { vect_no_align && { ! vect_hw_misalign } } } } } */

That is, run the check everywhere and expect it to fail for effective
targets for which vect_no_align is true and vect_hw_misalign is false.

Tested on i686-pc-linux-gnu and arm-none-eabi.  I'm enough confused that
I'm not going to call this one obvious, it needs a sanity check from
someone else; OK for trunk?

Janis
2012-06-27  Janis Johnson  

* gcc.dg/vect/vect-50.c: Combine two scans.

Index: gcc.dg/vect/vect-50.c
===
--- gcc.dg/vect/vect-50.c   (revision 189025)
+++ gcc.dg/vect/vect-50.c   (working copy)
@@ -61,8 +61,7 @@
align the store will not force the two loads to be aligned).  */
 
 /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
"vect" { xfail { vect_no_align } } } }  */
-/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
"vect" { target vect_hw_misalign } } } */
+/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
"vect" { xfail { vect_no_align && {! vect_hw_misalign } } } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using 
peeling" 1 "vect" { xfail { vect_no_align || {! vector_alignment_reachable} } } 
} } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using 
versioning." 3 "vect" { target vect_no_align } } } */
 /* { dg-final { scan-tree-dump-times "Alignment of access forced using 
versioning." 1 "vect" { target { {! vector_alignment_reachable} && { {! 
vect_no_align } && {! vect_hw_misalign } } } } } } */

Re: [testsuite] gcc.dg/vect/vect-50.c: combine two scans

[Janis Johnson]

On 06/27/2012 05:05 PM, Mike Stump wrote:
> On Jun 27, 2012, at 3:36 PM, Janis Johnson wrote:
>> These scans from gcc.dg/vect/vect-50.c, and others similar to them in
>> other vect tests, hurt my brain:
>>
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
>> "vect" { xfail { vect_no_align } } } }  */
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
>> "vect" { target vect_hw_misalign } } } */
>>
>> Both of these PASS for i686-pc-linux-gnu, causing duplicate lines in the
>> gcc test summary.  I'm pretty sure the following accomplishes the same
>> goal:
>>
>> /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 2 
>> "vect" { xfail { vect_no_align && { ! vect_hw_misalign } } } } } */
> 
> I don't think so?  The first sets the xfail status for the testcase.  If you 
> change the condition, you can't the xfail state for some targets, which would 
> be wrong (without a vec person chiming in).

The two checks are run separately.  The first one runs everywhere and
is expected to fail for vect_no_align.  The second is only run for
vect_hw_misalign.  Targets for which vect_no_align is false and
vect_hw_misliang is true get two PASS reports.

> I'd like to think you can compose the two with some spelling...  I just don't 
> think this one is it.?

No, there is no way to combine "target" and "xfail", although since we
intercept them we could presumably come up with a way to do that, with
syntax and semantics we design.

> I grepped around and found:
> 
>   /* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } 
> xfail *-*-* } 8 } */
> 
> which might have the right way to spell it, though, I always test to ensure 
> the construct does what I want.

Nope.  That should be flagged as an error by dg-message but it's
passed through GCC's process-message which ignore errors (a bug)
and simply ignores the directive.  I'm currently trying a fix to
not ignore errors from dg-error/dg-warning/dg-message and will then
fix up the broken tests.

>> That is, run the check everywhere
> 
> We don't want to run the test on other than vect_hw_misalign targets, right?
> 

I don't know, but right now it's run everywhere at least once.

Janis

[testsuite] gcc.dg/Wstrict-aliasing-converted-assigned.c: fix dg-message errors

[Janis Johnson]

Test gcc.dg/Wstrict-aliasing-converted-assigned.c uses a combination of
"target" and "xfail" selectors in a way that would be nice if it worked,
but it doesn't.  Unfortunately the local code to override dg-error and
friends ignores errors, so directives with errors have been silently
skipped.  I plan to fix that after fixing the affected tests.

This patch causes the affected dg-message directives in this test to be
XFAIL'd everywhere, with a comment asking that when the test starts
passing on the relevant targets, the "xfail" be replaced with a "target"
list.  It also adds comments to the dg-message directives to make their
messages unique in the test summary.

Tested on i686-pc-linux-gnu; OK for trunk?

Janis
2012-06-28  Janis Johnson  

* gcc.dg/Wstrict-aliasing-converted-assigned.c: Fix syntax
errors in dg-message directives, add comments.

Index: gcc.dg/Wstrict-aliasing-converted-assigned.c
===
--- gcc.dg/Wstrict-aliasing-converted-assigned.c(revision 189025)
+++ gcc.dg/Wstrict-aliasing-converted-assigned.c(working copy)
@@ -5,9 +5,12 @@
 int foo()
 {
   int i;
-  *(long*)&i = 0;  /* { dg-warning "type-punn" } */
+  *(long*)&i = 0;  /* { dg-warning "type-punn" "type-punn" } */
   return i;
 }
 
-/* { dg-message "does break strict-aliasing" "" { target { *-*-* && lp64 } 
xfail *-*-* } 8 } */
-/* { dg-message "initialized" "" { target { *-*-* && lp64 } xfail *-*-* } 8 } 
*/
+/* These messages are only expected for lp64, but fail there.  When they
+   pass for lp64, replace "xfail *-*-*" with "target lp64".  */
+
+/* { dg-message "does break strict-aliasing" "break" { xfail *-*-* } 8 } */
+/* { dg-message "initialized" "init" { xfail *-*-* } 8 } */

[testsuite] add required comments to dg-message directives in g++.dg

[Janis Johnson]

Several tests in g++.dg use dg-message with a target list and line
number but without the comment field, which is required when those
additional arguments are used.  The local replacement of dg-message
silently ignores errors (something I plan to fix), so the checks have
been ignored.  Unprocessed notes (as opposed to errors and warning)
in compiler output are intentionally ignored, so this wasn't noticed
before..

This patch adds the required comments, and the tests now pass on
i686-pc-linux-gnu.  OK for trunk?

Janis
2012-06-28  Janis Johnson  

* g++.dg/template/error46.C: Add missing comment to dg-message.
* g++.dg/template/crash107.C: Likewise.
* g++.dg/template/error47.C: Likewise.
* g++.dg/template/crash108.C: Likewise.
* g++.dg/overload/operator5.C: Likewise.

Index: g++.dg/template/error46.C
===
--- g++.dg/template/error46.C   (revision 189025)
+++ g++.dg/template/error46.C   (working copy)
@@ -8,4 +8,4 @@
 {
   foo(A<0>(), A<1>()); // { dg-error "no matching" }
 }
-// { dg-message "candidate|parameter 'N' ('0' and '1')" { target *-*-* } 9 }
+// { dg-message "candidate|parameter 'N' ('0' and '1')" "" { target *-*-* } 9 }
Index: g++.dg/template/crash107.C
===
--- g++.dg/template/crash107.C  (revision 189025)
+++ g++.dg/template/crash107.C  (working copy)
@@ -14,7 +14,7 @@
 }
 };
 Vec v(3,4,12); // { dg-error "no matching" }
-// { dg-message "note" { target *-*-* } 16 }
+// { dg-message "note" "note" { target *-*-* } 16 }
 Vec V(12,4,3);  // { dg-error "no matching" }
-// { dg-message "note" { target *-*-* } 18 }
+// { dg-message "note" "note" { target *-*-* } 18 }
 Vec c = v^V;   // { dg-message "required" }
Index: g++.dg/template/error47.C
===
--- g++.dg/template/error47.C   (revision 189025)
+++ g++.dg/template/error47.C   (working copy)
@@ -6,4 +6,4 @@
 {
   foo(0, p); // { dg-error "no matching" }
 }
-// { dg-message "candidate|parameter 'T' ('int' and 'void*')" { target *-*-* } 
7 }
+// { dg-message "candidate|parameter 'T' ('int' and 'void*')" "" { target 
*-*-* } 7 }
Index: g++.dg/template/crash108.C
===
--- g++.dg/template/crash108.C  (revision 189025)
+++ g++.dg/template/crash108.C  (working copy)
@@ -2,4 +2,4 @@
 
 template struct A {A(int b=k(0));}; // { dg-error "arguments" }
 void f(int k){A a;} // // { dg-error "parameter|declared" }
-// { dg-message "note" { target *-*-* } 3 }
+// { dg-message "note" "note" { target *-*-* } 3 }
Index: g++.dg/overload/operator5.C
===
--- g++.dg/overload/operator5.C (revision 189025)
+++ g++.dg/overload/operator5.C (working copy)
@@ -13,4 +13,4 @@
   const String& b,
   bool ignoreCase) {
   return ignoreCase ? equalIgnoringCase(a, b) : (a == b); } // { dg-error 
"ambiguous" }
-// { dg-message "note" { target *-*-* } 15 }
+// { dg-message "note" "note" { target *-*-* } 15 }

[testsuite] g++.dg/cpp0x/nullptr19.c: remove duplicate dg-message

[Janis Johnson]

Test g++.dg/cpp0x/nullptr19.c contains the following:

char* k( char* );  /* { dg-message "note" } { dg-message "note" } */
nullptr_t k( nullptr_t ); /* { dg-message "note" } { dg-message "note" } */

Having two test directives on a line should have resulted in an ERROR
but the local replacement of dg-warning silently ignores errors
(something I plan to fix).  There are two notes for each of these lines,
identical but after different candidate lists.  Since they are identical
DejaGnu removes both of them after one has been processed, and there is
apparently no way to check for both of them.  At least with this patch
we'll correctly check for one for each line.

Tested on i686-pc-linux-gnu; OK for trunk?

Janis
2012-06-28  Janis Johnson  

* g++.dg/cpp0x/nullptr19.c: Remove exta directives on same line.

Index: g++.dg/cpp0x/nullptr19.C
===
--- g++.dg/cpp0x/nullptr19.C(revision 189025)
+++ g++.dg/cpp0x/nullptr19.C(working copy)
@@ -5,8 +5,8 @@
 
 typedef decltype(nullptr) nullptr_t;
 
-char* k( char* );  /* { dg-message "note" } { dg-message "note" } */
-nullptr_t k( nullptr_t ); /* { dg-message "note" } { dg-message "note" } */
+char* k( char* );  /* { dg-message "note" } */
+nullptr_t k( nullptr_t ); /* { dg-message "note" } */
 
 void test_k()
 {

Re: [testsuite] gcc.dg/vect/vect-50.c: combine two scans

[Janis Johnson]

On 06/28/2012 08:02 PM, Mike Stump wrote:
> On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote:
>> No, there is no way to combine "target" and "xfail",
> 
> Ah...  Grrr  I hate non-composability.  Given that, I think the original 
> patch is fine, subject of course to the wants and wishes of vect people.

I should have said that *currently* there is no way to combine them.
We override dg-process-target and can come up with a way to provide
both "target" and "xfail" in the target-selector.  Something like:

  target { selector } xfail { selector }

where "target" is the first argument, "xfail" is the third.
Selectors can be lists of target triplets, but those can be within
braces making them a single argument.  What do you think?

Janis

MAINTAINERS: add myself as testsuite maintainer

[Janis Johnson]

Mike Stump says he got word that I am reinstated as a testsuite
maintainer so I added myself to the MAINTAINERS file (with, I now
see, a typo in the ChangeLog).

2012-07-02  Janis Johnson  

* MAINTAINERS (Various Mainterers): Add myself as testsuite
maintainer.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 189165)
+++ MAINTAINERS (revision 189166)
@@ -249,6 +249,7 @@ loop infrastructure Zdenek Dvorak   ook@u
 OpenMP Jakub Jelinek   ja...@redhat.com
 testsuite  Rainer Orth r...@cebitec.uni-bielefeld.de
 testsuite  Mike Stump  mikest...@comcast.net
+testsuite  Janis Johnson   jani...@codesourcery.com
 register allocationVladimir Makarovvmaka...@redhat.com

 Note that individuals who maintain parts of the compiler need approval to