MAINTAINERS: resign as testsuite maintainer, update address
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
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 san...@codesourcery.com 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: [testsuite patch] add code to arm_thumbX_ok to exercise ABI
On 08/18/2014 07:36 AM, Christophe Lyon wrote: On 8 August 2014 02:30, Janis Johnson janis_john...@mentor.com 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
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 jani...@codesourcery.com
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: [testsuite patch] add __ARM_ARCH check for arm_v8_neon_ok
On 08/14/2014 01:06 AM, Ramana Radhakrishnan wrote: On Mon, Aug 11, 2014 at 11:01 PM, Janis Johnson janis_john...@mentor.com 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
[testsuite patch] fix ARM tests with options that conflict with thumb1
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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 ()
[testsuite patch] add code to arm_thumbX_ok to exercise ABI
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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 stdlib.h
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 } */
Re: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c
On 01/27/2014 10:51 PM, Senthil Kumar Selvaraj wrote: This is on trunk - I was under the impression that it is always trunk, unless otherwise stated? getpid doesn't really make sense for bare metal targets, I would think? Regards Senthil On Mon, Jan 27, 2014 at 01:04:48PM +, Umesh Kalappa wrote: Senthil, Please do let us know the gcc version ,I couldn't locate the file pr58419.c in the GCC 4.8.1 source . To go with the below problem ,you can attributed the getpid() function as weak (http://www.embedded-bits.co.uk/2008/gcc-weak-symbols/). ~Umesh -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Senthil Kumar Selvaraj Sent: 27 January 2014 15:18 To: gcc@gcc.gnu.org Subject: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c All, gcc.c-torture/execute/pr58419.c has a call to getpid, and this causes a linker error on the AVR (embedded) target. Is the call intentional, and if yes, how should this be fixed for targets that don't support an OS? Regards Senthil The testcase in the PR had a call to printf. The modified test doesn't call printf, and doesn't declare getpid. I assume that getpid is called simply to have an external call, but there must be something that could be used instead that is available for any target. Jeff, you added this test, would you please take a look at it? Janis
Re: [patch] [arm] ARM Cortex-M3/M4 tuning
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 jul...@codesourcery.com Joey Ye joey...@arm.com * 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 joey...@arm.com * 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.
Re: dejagnu multilib options and dg-{add|additional-}options
On 08/27/2013 06:52 AM, Marcus Shawcroft wrote:
On 23 July 2013 17:40, Janis Johnson janis_john...@mentor.com wrote:
On 07/22/2013 02:59 AM, Vidya Praveen wrote:
Hello,
There are 42 test files (25 under gcc.dg) that specifies
{ dg-add-options bind_pic_locally }
in the regression testsuite. The procedure add_options_for_bind_pic_locally
from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is
passed
respectively. But this is added before the dejagnu multilib options are
added.
So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
(see gcc/common.opt). This should have been the behaviour since the patch
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all
-fPIC
-fPIE variants in a Negative loop, was applied.
I tried fixing this in dejagnu/target.exp by adding the multilib options
before
the other options:
default_target_compile:
append add_flags [board_info $dest multilib_flags]
---
set add_flags [board_info $dest multilib_flags] $add_flags
and ran regressions for x86_64-unknown-linux-gnu before and after the
change.
The only difference in the results after the change was 24 new PASSes which
are from the testcases which either use bind_pic_locally or that use
-fno-pic.
(Interestingly, there are many test files that bind_pic_locally pass without
any issue before and after the change.)
I tend to think that the options added from the test files should always
win.
Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
best place to fix this and the way it tried to fix? Any better suggestions?
Though this case is to do with -fPIC, I'm sure there are other options which
when they come as multilib options might have same issue with the some of
the
options added by the test files or the default options.
Regards
VP
Ideally we would ask for that change in DejaGnu, but relying on such a
change would require everyone testing GCC to upgrade to a version of
DejaGnu with that fix, and I don't think we're ready to do that.
Tests that add options that might override or conflict with multilib
flags should check for those flags first and skip the test if they are
used. For examples, see tests in gcc.target/arm that use dg-skip-if.
Umm, the purpose of bind_pic_locally appears to be to detect the use
of -fPIC and override that behavior with -fPIE. If I understand the
above paragraph correctly then bind_pic_locally is fundamentally
broken and all of the tests that use it need rewriting to skip if
-fPIC or -fpic is in use?
Cheers
/Marcus
That is correct. There should probably be an effective-target check
bind_pic_locally_ok that fails if adding -fpie or -fPIE doesn't have the
expected result, and the tests that use dg-add-options bind_pic_locally
should be skipped if bind_pic_locally_ok fails.
Janis
Re: Ping: testsuite patches ({1,2,6,10,12}/14)
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
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 jani...@codesourcery.com
* 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/gcc.target/arm/atomic-op
[testsuite] skip gcc.target/arm/pr19599.c for -mthumb
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 jani...@codesourcery.com * 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: gfortran-dg-runtest, torture options
On 08/13/2013 04:06 AM, Thomas Schwinge wrote: Hi! I noticed something strange in the libgomp testresults (but not necessarily specific to libgomp): an arbitrary set of the Fortran execution tests are run just for -O, and others for each of the full set of torture options: -O0, -O1, -O2, and so on. After some time I realized it's the set of tests that contain an explicit »dg-do run« directive that are run for all torture levels, and the tests that inherit the default »set dg-do-what-default run« from libgomp/testsuite/lib/libgomp.exp are only run for -O. This is coming from the special handling in gcc/testsuite/lib/gfortran-dg.exp:gfortran-dg-test (which seems to be present approximately forever). Should this consider the dg-do-what-default case, too? Why is torture testing done only for execution tests? And, why only for Fortran? Is this behavior generally intentional -- of course, bigger testing coverage is nice, but this seems a bit arbitrary to me? You're right, it looks odd, but I can't say whether it's right or wrong. Sometimes these things just grow over the years. Fortran people might want to take a closer look to see how they want the tests to be run now. gfortran.fortran-torture/compile has torture tests for Fortran compiles, and C has torture tests for both compile and execute in a couple of places. Janis
Re: dejagnu multilib options and dg-{add|additional-}options
On 07/22/2013 02:59 AM, Vidya Praveen wrote:
Hello,
There are 42 test files (25 under gcc.dg) that specifies
{ dg-add-options bind_pic_locally }
in the regression testsuite. The procedure add_options_for_bind_pic_locally
from lib/target-supports.exp adds -fPIE or -fpie when -fPIC or -fpic is passed
respectively. But this is added before the dejagnu multilib options are added.
So when -fPIC is passed as a multilib option, -fPIE will be unset by -fPIC
(see gcc/common.opt). This should have been the behaviour since the patch
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01026.html that brings all -fPIC
-fPIE variants in a Negative loop, was applied.
I tried fixing this in dejagnu/target.exp by adding the multilib options
before
the other options:
default_target_compile:
append add_flags [board_info $dest multilib_flags]
---
set add_flags [board_info $dest multilib_flags] $add_flags
and ran regressions for x86_64-unknown-linux-gnu before and after the change.
The only difference in the results after the change was 24 new PASSes which
are from the testcases which either use bind_pic_locally or that use -fno-pic.
(Interestingly, there are many test files that bind_pic_locally pass without
any issue before and after the change.)
I tend to think that the options added from the test files should always win.
Please correct me if I'm wrong. If I'm right, is dejagnu/target.exp is the
best place to fix this and the way it tried to fix? Any better suggestions?
Though this case is to do with -fPIC, I'm sure there are other options which
when they come as multilib options might have same issue with the some of the
options added by the test files or the default options.
Regards
VP
Ideally we would ask for that change in DejaGnu, but relying on such a
change would require everyone testing GCC to upgrade to a version of
DejaGnu with that fix, and I don't think we're ready to do that.
Tests that add options that might override or conflict with multilib
flags should check for those flags first and skip the test if they are
used. For examples, see tests in gcc.target/arm that use dg-skip-if.
Janis
[patch] fix libgcc configure for powerpc-*-eabispe
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 jani...@codesourcery.com
* 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: [PATCH, ARM] Fix unrecognizable vector comparisons
On 07/08/2013 08:32 AM, Zhenqiang Chen wrote:
On 8 July 2013 20:57, Ramana Radhakrishnan ramana@googlemail.com 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 (MODEmode, 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
zhenqiang.c...@linaro.org wrote:
On 18 June 2013 17:41, Ramana Radhakrishnan ramra...@arm.com wrote:
On 06/18/13 09:50, Zhenqiang Chen wrote:
Hi,
During expand, function vcondmodemode 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 (MODEmode))
+ 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
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 jani...@codesourcery.com
* 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 lfd2 } } */
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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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 al...@redhat.com. */
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
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 jani...@codesourcery.com
* 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)));
Re: [patch testsuite]: Fix some tests for LLP64 targets
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 kti...@redhat.com * 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, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
On 02/28/2013 02:06 AM, Julian Brown wrote:
On Wed, 27 Feb 2013 11:04:04 -0800
Janis Johnson janis_john...@mentor.com 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, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode
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
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 marcus.shawcr...@arm.com * g++.old-deja/g++.pt/ptrmem6.C(main): Add xfail aarch64*-*-*. OK. Janis
dummy DejaGnu board files
I've been using a couple of DejaGnu board files to test multilibs for
which I don't have any way to execute tests, and for which I can't even
link because I don't have compatible libraries. I'd like to share but
don't know where to put them; any suggestions?
Janis
Index: dummy-link.exp
===
--- dummy-link.exp (revision 0)
+++ dummy-link.exp (revision 0)
@@ -0,0 +1,63 @@
+
+#
+# File: dummy-link.exp
+# Author: Janis Johnson jani...@codesourcery.com
+# Date: 2013-02-25
+#
+# Contents:
+#
+# DejaGNU board configuration file for a null target board and no
+# libraries.
+#
+
+
+load_generic_config sim
+set_board_info hostname dummy-link
+set board_info(localhost,isremote) 0
+process_multilib_options
+
+# Override target_compile to downgrade link to compile and skip compile
+# of multiple source files.
+if { [info procs saved_target_compile] == [list] } {
+rename target_compile saved_target_compile
+proc target_compile { source destfile type options } {
+ if { $type == executable } {
+ set path_string gcc/testsuite
+ set i1 [string first $path_string $source]
+ set i2 [string last $path_string $source]
+ if { [regexp $path_string $options]
+|| $i1 != $i2 } {
+ global compiler_conditional_xfail_data
+ set compiler_conditional_xfail_data [list]
+ lappend compiler_conditional_xfail_data unknown-*-*
+ lappend compiler_conditional_xfail_data *
+ return skip compile of multiple source files and expect it to
fail
+ }
+ set type object
+ regsub .exe $destfile .o destfile
+ send_user target_compile: change executable to object\n
+ }
+ return [saved_target_compile $source $destfile $type $options]
+}
+}
+
+# ${tool}_check_compile reports the status of the compile step, and the
+# return value determines whether an execution step is run or is
+# reported as unresolved. Let the real one report whether the compile
+# passed or failed, but always treat the execution as unresolved.
+if { [info procs saved_check_compile] == [list] } {
+rename ${tool}_check_compile saved_check_compile
+proc ${tool}_check_compile { testcase option objname gcc_output } {
+ set retval [saved_check_compile $testcase $option $objname $gcc_output]
+ return 0
+}
+}
+
+# Override ${target}_load. Tests don't get this far, but it's needed
+# for GCC effective-target checks that run executables.
+foreach t $target_list {
+proc ${t}_load { args } {
+send_user dummy load does nothing\n
+return [list fail skip execution for dummy.exp]
+}
+}
Index: dummy-run.exp
===
--- dummy-run.exp (revision 0)
+++ dummy-run.exp (revision 0)
@@ -0,0 +1,24 @@
+
+#
+# File: dummy-run.exp
+# Author: Janis Johnson jani...@codesourcery.com
+# Date: 2013-02-25
+#
+# Contents:
+#
+# DejaGNU board configuration file for a null target board.
+#
+
+
+load_generic_config sim
+set_board_info hostname dummy-run
+set board_info(localhost,isremote) 0
+process_multilib_options
+
+# Override ${target}_load to do nothing.
+foreach t $target_list {
+proc ${t}_load { args } {
+send_user dummy load does nothing\n
+return [list unresolved ]
+}
+}
Re: [4.7, testsuite] Clear hwcap_2 with Sun ld
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 r...@cebitec.uni-bielefeld.de * 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,testsuite] Added test for PR 55987
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 til...@code-monkey.de
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
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 greta.yo...@arm.com * gcc.target/arm/interrupt-1.c: Fix for thumb mode. * gcc.target/arm/interrupt-2.c: Likewise.
[testsuite] commited: fix typo in 4.7 testsuite/lib/target-supports.exp
This patch fixes the typo reported in PR testsuite/56206. Checked in as
obvious.
Janis
2013-02-04 Janis Johnson jani...@codesourcery.com
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: testsuite] clean up convoluted dg-final directive in vect-multitypes-12.c
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
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] clean up convoluted dg-final directive in vect-multitypes-12.c
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 jani...@codesourcery.com
* 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
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] replace gcc.target/arm/ftest-*.c with compile-only tests
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 jani...@codesourcery.com * 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 stdio.h +#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
Re: PING: gcc.target/arm: skip 5 tests for flag conflicts
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 jani...@codesourcery.com
* 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
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
Re: [testsuite] fix ARM test gcc.target/arm/neon-vld1_dupQ.c
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
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
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
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 dblai...@gmail.com 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 dblai...@gmail.com * dg-extract-results.sh: Constrain the start-of-log pattern. Janis
[testsuite] fix loop index for gcc.dg/webizer.c
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 jani...@codesourcery.com
* 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
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
PING: gcc.target/arm: skip 5 tests for flag conflicts
Richard, 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. 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
Richard, In December I submitted a patch to replace ftest*.c in gcc.target/arm with compile-only tests: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01339.html. 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
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 jani...@codesourcery.com
* 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
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
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 jani...@codesourcery.com
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
}
}
[v3 testsuite] gdb-test.exp: catch error running gdb command
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 jani...@codesourcery.com
* 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
}
[testsuite] replace gcc.target/arm/ftest-*.c with compile-only tests
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 jani...@codesourcery.com
* 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 stdio.h
+#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
skipping run or link steps in tests
Occasionally I try to run GCC tests using flags for which I don't have
the required target platform, or even compatible libraries. I usually
hack up several test files to kind of get what I want, but it's a pain.
Right now, for example, I'm trying to run upstream gcc.target/arm tests
for several sets of options that are not supported in my test
environment for upstream tools. There are probably lots of others in
the same situation, so I'd like to make this easier for all of us.
It's easy to skip test execution by using a do-nothing $tool_load
procedure in the board file, but would also be fairly easy to skip it by
checking for a flag in a few places in GCC's DejaGNU support. The
advantage of checking for a flag is that it could be set for the board,
or globally, or for an individual test with something like
{ dg-skip-run-if comment { selector } [{ include-opts } [{ exclude-opts }]] }
This would allow the equivalent of dg-do run for some effective
targets and dg-do link for others. (There are a couple of tests that
currently have two dg-do directives with different keywords for
different selectors, but that doesn't do what the test authors intended.)
Another possibility is to specify globally, or for a board, or for an
individual test, the highest level of dg-do keyword to support, ordered
{ preprocess, compile, link, run }. Perhaps within a test this would be
done with
{ dg-do run }
{ dg-do-link-if comment { selector } [{ include-opts } [{ exclude-opts }]] }
{ dg-do-compile-if comment { selector } [{ include-opts } [{ exclude-opts }]]
}
where the dg-do-*-if directives would only be used if the test would
otherwise use a later step. This would need to be tied in with uses of
dg-do-what-default for several sets of tests.
Do other people have ideas for downgrading how much work is done in a
test, or have local solutions?
Janis
Re: [PATCH, ARM] Fix PR44557 (Thumb-1 ICE)
On 10/19/2012 11:41 PM, Ramana Radhakrishnan wrote:
On Tue, Oct 16, 2012 at 10:25 AM, Chung-Lin Tang
clt...@codesourcery.com 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
Re: Questions about the dg-do directive
On 10/16/2012 07:14 AM, Andreas Schwab wrote:
domi...@lps.ens.fr (Dominique Dhumieres) writes:
These questions are motivated by the comments #4 to #15 of pr54407.
The bottom line is that
{ dg-do compile targets1 }
{ dg-do run targets2 }
behaves as
{dg-do run { targets1 targets2 } }
while
{ dg-do run targets1 }
{ dg-do compile targets2 }
as
{ dg-do compile { targets1 targets2 } }
(1) Is the above correct?
(2) If yes, is it a (undocumented) feature or a bug?
That's just the way it works, so I suppose you could call it a feature.
DejaGnu doesn't support having different dg-do-what values for different
targets within a test, although it can be done from outside the test in
the .exp file. Tests that try to do that are broken.
From dg.exp:
# Multiple instances are supported (since we don't support target and xfail
# selectors on one line), though it doesn't make much sense to change the
# compile/assemble/link/run field. Nor does it make any sense to have
# multiple lines of target selectors (use one line).
Andreas.
I wouldn't rely on that feature, either. We have much better ways in
local test directives to skip and xfail tests for different targets.
Janis
Re: Questions about the dg-do directive
On 10/16/2012 03:31 PM, Dominique Dhumieres wrote:
Thanks for the quick answer.
That's just the way it works, so I suppose you could call it a feature.
So the answer to (1) is yes and to (2) it is a poorly documented feature.
May be the restriction to one dg-do directive should be added to
http://gcc.gnu.org/wiki/HowToPrepareATestcase .
And http://gcc.gnu.org/onlinedocs/gccint/Directives.html#Directives .
In gcc/testsuite/* I have found 27 instances of such double directives
most of the in the powerpc tests (gcc.target/powerpc/altivec*).
I can provide a list if it helps.
... We have much better ways in
local test directives to skip and xfail tests for different targets.
Could you elaborate please? AFAIU skip or xfail do not allow to do
what was intended in the gcc.target/powerpc/altivec* cases for instance:
run for powerpc*-*-* vmx_hw and compile for
powerpc*-*-* { ! vmx_hw }.
No, those would need to be done in separate tests, or via a different
.exp file (perhaps in a subdirectory) that sets dg-do-what-default
to compile or run depending on the target; there are several sets
of tests that already do that.
Janis
Re: [PATCH] Adjust target for vect/pr48765.c
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 jseym...@codesourcery.com
* 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
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01320.html 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
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 jseym...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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.
Richard,
I'll answer your last question and then we can figure out what to do
about my proposed changes to limit multilibs with which specific tests
are run.
Flags from dg-options are on the command line before multilib options
because that's how it's always been handled in DejaGnu, specifically in
default_target_compile in DejaGnu's lib/target.exp, which puts multilib
flags at the end of the long list of options it passes to the compiler.
The GCC testsuite could override that proc but it would be messy and
would probably break lots of tests that expect multilib options to
override everything else.
The purpose of multilib options is to run every single test for that
multilib and provide as much coverage as possible for the multilib.
Tests for specific -march/-mcpu/whatever options need to be skipped for
multilibs that conflict with those options. Similarly, a test for
specific functionality that doesn't use dg-options can be skipped for
all multilibs that don't support that functionality.
If each multilib specifies -march/-mcpu/whatever then tests that specify
conflicting options will never be run. If there's a multilib that uses
Re: [testsuite] gcc.target/arm/div64-unwinding.c: xfail for linux
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 jani...@codesourcery.com
* 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 stdlib.h
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: [AVR] Missing avr51-flash1.x in avr target specific tests?
On 10/04/2012 07:06 AM, Georg-Johann Lay wrote: Senthil Kumar Selvaraj wrote: Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently fail with an unable to open linker script error for that file. Is that linker script supposed to be checked into source control? Or am I missing some configure/build option? I found no way to specify a linker script for one single test and supply that linker script in the testsuite source tree. It's likely that I used the wrong approach just because my limited knowledge on DejaGNU and GCC testsuite framework. The linker script must be located in a place where the compiler will search for it, e.g. some directory that contains the .x and that you added per -L to the ldflags in your DejaGNU board description. Johann If the linker will look in the directory containing the source file you can check it in there and use dg-additional-files in the test to copy the file to the host. Janis
Re: [PATCH, ARM] Fix PR44557 (Thumb-1 ICE)
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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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 stdlib.h
Re: [patch testsuite]: Fix failing test for llp64 in gcc.dg/tree-ssa
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 } } */
[testsuite] gcc.target/arm: skip 5 tests for flag conflicts
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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: [testsuite] support using target and xfail together
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
On 09/19/2012 10:48 AM, Mike Stump wrote:
On Sep 19, 2012, at 10:35 AM, Janis Johnson janis_john...@mentor.com 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
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] remove dg-do run from a vect test
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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
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 jani...@codesourcery.com
* 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 { scan-tree-dump-times can't determine dependence 2 vect {
xfail vect_multiple_sizes } } } */
+/* { 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 } } } */
/* { dg-final { cleanup-tree-dump vect } } */
Index: gcc.dg/vect/no-vfa-vect-79.c
===
--- gcc.dg/vect/no-vfa-vect-79.c
[testsuite] vect/fast-math-pr35982: skip check instead of xfail
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 jani...@codesourcery.com
* 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
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
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 jani...@codesourcery.com
* 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: [Patch ARM testsuite] fix 3 tests for big-endian
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
Re: [PATCH, ARM] Constant vector permute for the Neon vext insn
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 rearn...@arm.com 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, testsuite] No short enum in tree-ssa test
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 joey...@arm.com
* 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: Excluding dejagnu testcases for subtargets
On 08/11/2012 09:18 AM, Senthil Kumar Selvaraj wrote:
On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote:
On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote:
Hi,
What is the recommended way to skip specific (non target specific)
testcases for a subtargets?
There are a bunch of tests in the gcc testsuite that are too big (in
terms of code size or memory) for a subtarget of the avr target. The
subtarget is specified in the dejagnu board configuration file
(set_board_info cflags -mmcu subtarget name).
Using dg-skip-if with -mmcu subtarget name for the include part did
not work. Looking at the source (target-supports-dg.exp) showed that it
doesn't consider board_info cflags. Only board_info multilib_flags,
flags specified in dg-options, $TOOL_OPTIONS and $TEST_ALWAYS_FLAGS
appear to be considered.
Should we set the -mmcu option to multilib_flags instead of cflags in
the board config? Should we use --tool_opt in RUNTESTFLAGS? How do
other targets handle this?
Regards
Senthil
Probably check-flags in target-supports-dg.exp should check cflags
in the board_info along with the other flags. Can you try that to
see if it does what you need?
Yes it does. The patch below did the job.
Please submit it, with a ChangeLog entry, to gcc-patc...@gcc.gnu.org.
Is there a reason why cflags wasn't included before?
Because I didn't know about it. It wasn't intentional.
Janis
Regards
Senthil
diff --git a/gcc/testsuite/lib/target-supports-dg.exp
b/gcc/testsuite/lib/target-supports-dg.exp
index 2f6c4c2..bdf7476 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -304,6 +304,9 @@ proc check-flags { args } {
# If running a subset of the test suite, $TEST_ALWAYS_FLAGS may not
exist.
catch {append compiler_flags $TEST_ALWAYS_FLAGS }
set dest [target_info name]
+if [board_info $dest exists cflags] {
+append compiler_flags [board_info $dest cflags]
+}
if [board_info $dest exists multilib_flags] {
append compiler_flags [board_info $dest multilib_flags]
}
Re: Excluding dejagnu testcases for subtargets
On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote: Hi, What is the recommended way to skip specific (non target specific) testcases for a subtargets? There are a bunch of tests in the gcc testsuite that are too big (in terms of code size or memory) for a subtarget of the avr target. The subtarget is specified in the dejagnu board configuration file (set_board_info cflags -mmcu subtarget name). Using dg-skip-if with -mmcu subtarget name for the include part did not work. Looking at the source (target-supports-dg.exp) showed that it doesn't consider board_info cflags. Only board_info multilib_flags, flags specified in dg-options, $TOOL_OPTIONS and $TEST_ALWAYS_FLAGS appear to be considered. Should we set the -mmcu option to multilib_flags instead of cflags in the board config? Should we use --tool_opt in RUNTESTFLAGS? How do other targets handle this? Regards Senthil Probably check-flags in target-supports-dg.exp should check cflags in the board_info along with the other flags. Can you try that to see if it does what you need? Janis
Re: [PATCH, testsuite] New effective target long_neq_int
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 wschm...@linux.vnet.ibm.com
* sourcebuild.texi: Document long_neq_int effective target.
testsuite:
2012-08-09 Bill Schmidt wschm...@linux.vnet.ibm.com
* 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] Strength reduction part 3 of 4: candidates with unknown strides
On 08/08/2012 03:27 PM, Andrew Pinski wrote:
On Wed, Aug 8, 2012 at 3:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
wschm...@linux.vnet.ibm.com 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 wschm...@linux.ibm.com
* 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 wschm...@linux.ibm.com
* 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
http://gcc.gnu.org/onlinedocs/gccint/Effective_002dTarget-Keywords.html#Effective_002dTarget-Keywords.
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 } { } } */
long
f (int s, long c)
Re: [PATCH] Strength reduction part 3 of 4: candidates with unknown strides
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 hjl.to...@gmail.com wrote:
On Wed, Aug 1, 2012 at 10:36 AM, William J. Schmidt
wschm...@linux.vnet.ibm.com 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: [Test] Fix for PRPR53981
Yes, you can put it on the 4.6 branch. Janis On 08/03/2012 03:09 AM, Anna Tikhonova wrote: Ping 2012/7/27 Anna Tikhonova anna.m.tikhon...@gmail.com: Kirill has already checked it in for me, thanks! Btw, I have FSF copyright assignment. Is it possible to commit this patch to 4.6 branch? Since current ndk is based on 4.6 2012/7/25 Janis Johnson janis_john...@mentor.com: On 07/25/2012 03:58 AM, Anna Tikhonova wrote: Thanks! I've removed declarations. New patch attached. You're not listed as write after approval in the MAINTAINERS file; would you like me to check this in for you? I didn't check to see if you have an FSF copyright assignment because this is a very small patch. Janis
Re: PING [PATCH] Fix PR libstdc++/54036, problem negating DFP NaNs
On 08/01/2012 07:29 AM, Paolo Carlini wrote: Hi, On 08/01/2012 12:46 AM, Peter Bergner wrote: I'd like to ping the following libstdc++ DFP patch that fixes PR54036: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00959.html I think the patch is essentially Ok, but I would recommend giving Janis a chance to comment (say 24/48 h). It looks fine to me. Note that the patch only touches libstdc++-v3 code, thus the testcases should be added to libstdc++-v3/testsuite/decimal and the patch itself was missing a CC to libstdc++@. I agree. Janis
Re: [patch, fortran] Fix PR 54033, problems with -I
On 07/27/2012 01:06 PM, Thomas Koenig wrote:
Hi Janis,
On 07/26/2012 10:16 AM, Thomas Koenig wrote:
No test case because I couldn't figure out how to test for a
warning with no line number.
Try using line number 0.
That didn't work for me. Using
! { dg-do compile }
! { dg-options -I include_6.f90 -I missing_dir }
! { dg-warning not a directory missing directory target *-*-* 0 }
! { dg-warning does not exist nonexisting directory target *-*-* 0 }
end
got me
Warning: Include directory include_6.f90 does not exist^M
Warning: Include directory missing_dir does not exist^M
output is:
Warning: Include directory include_6.f90 does not exist^M
Warning: Include directory missing_dir does not exist^M
FAIL: gfortran.dg/include_6.f90 -O (test for excess errors)
Excess errors:
:0:0: Warning: Include directory include_6.f90 does not exist
:0:0: Warning: Include directory missing_dir does not exist
Use { target *-*-* } instead of target *-*-*.
Notice that the two warnings have the same text, so the directive
looking for not a directory will fail.
Janis
Re: [patch, fortran] Fix PR 54033, problems with -I
On 07/26/2012 10:16 AM, Thomas Koenig wrote: No test case because I couldn't figure out how to test for a warning with no line number. Try using line number 0. Janis
[testsuite] gcc.dg/pr45259.c: fix dg-options for non-fpic
Test gcc.dg/pr45259 fails on targets that don't support fpic because it
skips using -w and therefore gets pedantic warnings that are enabled by
default. This patch provides an alternate dg-option command to supply
options other than -fpic for targets that don't support fpic.
Checked in on trunk, coming soon to the 4.7 branch.
Janis
2012-07-26 Janis Johnson jani...@codesourcery.com
* gcc.dg/pr45259.c: Only -fpic depends on fpic support.
Index: gcc/testsuite/gcc.dg/pr45259.c
===
--- gcc/testsuite/gcc.dg/pr45259.c (revision 189892)
+++ gcc/testsuite/gcc.dg/pr45259.c (working copy)
@@ -1,6 +1,7 @@
/* PR debug/45259 */
/* { dg-do compile } */
-/* { dg-options -g -O2 -fpic -w { target fpic } } */
+/* { dg-options -g -O2 -w -fpic { target fpic } } */
+/* { dg-options -g -O2 -w { target { ! fpic } } } */
struct S { void (*bar) (long); };
struct T { struct S *t; };
[testsuite] fix g++.dg/cpp0x/nullptr21.C to be self-checking
This patch changes test g++.dg/cpp0x/nullptr21.C to be self-checking
instead of examining printf output via dg-output. Now it can be run
reliably on bare-metal platforms. I couldn't see any indication in the
test itself or in the gcc-patches archives to show that the printfs
were significant.
Checked in on mainline, coming soon to 4.7.
Janis
2012-07-25 Janis Johnson jani...@codesourcery.com
* g++.dg/cpp0x/nullptr21.c: Remove printfs, make self-checking.
Index: gcc/testsuite/g++.dg/cpp0x/nullptr21.C
===
--- gcc/testsuite/g++.dg/cpp0x/nullptr21.C (revision 189856)
+++ gcc/testsuite/g++.dg/cpp0x/nullptr21.C (working copy)
@@ -3,42 +3,53 @@
// Test throw and catch
-#include cstdio
+extern C void abort (void);
typedef decltype(nullptr) nullptr_t;
+int result[2];
+
+void __attribute__((noinline))
+foo (int i, int j)
+{
+ result[i] = j;
+}
+
int main()
{
try {
throw nullptr;
} catch (void*) {
-printf(Test 1 Fail);
+foo (0, 1);
} catch (bool) {
-printf(Test 1 Fail);
+foo (0, 2);
} catch (int) {
-printf(Test 1 Fail);
+foo (0, 3);
} catch (long int) {
-printf(Test 1 Fail);
+foo (0, 4);
} catch (nullptr_t) {
-printf(Test 1 OK);
+foo (0, 5);
} catch (...) {
-printf(Test 1 Fail);
- } // { dg-output Test 1 OK }
+foo (0, 6);
+ }
nullptr_t mynull = 0;
try {
throw mynull;
} catch (void*) {
-printf(Test 2 Fail);
+foo (1, 1);
} catch (bool) {
-printf(Test 2 Fail);
+foo (1, 2);
} catch (int) {
-printf(Test 2 Fail);
+foo (1, 3);
} catch (long int) {
-printf(Test 2 Fail);
+foo (1, 4);
} catch (nullptr_t) {
-printf(Test 2 OK);
+foo (1, 5);
} catch (...) {
-printf(Test 2 Fail);
- } // { dg-output Test 2 OK }
+foo (1, 6);
+ }
+
+ if (result[0] != 5 || result[1] != 5)
+abort ();
}
[testsuite] don't ignore errors for dg-error and friends
This patch prevents errors in dg-error, dg-warning, and dg-message from
being silently ignored by GCC's overrides for those procedures. It's
been tested on i686-pc-linux-gnu for the languages that use the overrides
(c,c++,fortran,objc,obj-c++). I scanned through target-specific tests
and didn't see anything problematic, but it's possible I missed something
and errors will be reported. Checked in on mainline, and I plan to add
it to 4.7 soon.
Janis
2012-07-24 Janis Johnson jani...@codesourcery.com
* lib/gcc-dg.exp (process-message): Don't ignore errors.
Index: testsuite/lib/gcc-dg.exp
===
--- testsuite/lib/gcc-dg.exp(revision 189790)
+++ testsuite/lib/gcc-dg.exp(working copy)
@@ -739,7 +739,7 @@
# Process the dg- directive, including adding the regular expression
# to the new message entry in dg-messages.
set msgcnt [llength ${dg-messages}]
-catch { eval $msgproc $dgargs }
+eval $msgproc $dgargs
# If the target expression wasn't satisfied there is no new message.
if { [llength ${dg-messages}] == $msgcnt } {
[testsuite] support using target and xfail together
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.
Janis
2012-07-24 Janis Johnson jani...@codesourcery.com
doc/sourcebuild.texi (Selectors): Document the use of target
and xfail used together.
testsuite/
* lib/target-supports-dg.exp (dg-require-effective-target,
dg-skip-if, dg-xfail-if, dg-xfail-run-if, dg-shouldfail): Call
dg-process-target-1 instead of dg-process-target.
(dg-process-target-1): Rename from dg-process-target.
(dg-process-target): New.
Index: doc/sourcebuild.texi
===
--- doc/sourcebuild.texi(revision 189790)
+++ doc/sourcebuild.texi(working copy)
@@ -1232,15 +1232,18 @@
A selector is:
@itemize @bullet
-@item one or more target triplets, possibly including wildcard characters
+@item one or more target triplets, possibly including wildcard characters;
+use @samp{*-*-*} to match any target
@item a single effective-target keyword (@pxref{Effective-Target Keywords})
@item a logical expression
@end itemize
-Depending on the
-context, the selector specifies whether a test is skipped and reported
-as unsupported or is expected to fail. Use @samp{*-*-*} to match any
-target.
+Depending on the context, the selector specifies whether a test is
+skipped and reported as unsupported or is expected to fail. A context
+that allows either @samp{target} or @samp{xfail} also allows
+@samp{@{ target @var{selector1} xfail @var{selector2} @}}
+to skip the test for targets that don't match @var{selector1} and the
+test to fail for targets that match @var{selector2}.
A selector expression appears within curly braces and uses a single
logical operator: one of @samp{!}, @samp{}, or @samp{||}. An
Index: testsuite/lib/target-supports-dg.exp
===
--- testsuite/lib/target-supports-dg.exp(revision 189790)
+++ testsuite/lib/target-supports-dg.exp(working copy)
@@ -208,7 +208,7 @@
# Evaluate selector if present.
if { [llength $args] == 2 } {
- switch [dg-process-target [lindex $args 1]] {
+ switch [dg-process-target-1 [lindex $args 1]] {
S { }
N { return }
}
@@ -359,7 +359,7 @@
}
set selector [list target [lindex $args 1]]
-if { [dg-process-target $selector] == S } {
+if { [dg-process-target-1 $selector] == S } {
if [check-flags $args] {
upvar dg-do-what dg-do-what
set dg-do-what [list [lindex ${dg-do-what} 0] N P]
@@ -383,7 +383,7 @@
}
set selector [list target [lindex $args 1]]
-if { [dg-process-target $selector] == S } {
+if { [dg-process-target-1 $selector] == S } {
global compiler_conditional_xfail_data
# The target list might be an effective-target keyword. Replace
@@ -418,7 +418,7 @@
}
set selector [list target [lindex $args 1]]
-if { [dg-process-target $selector] == S } {
+if { [dg-process-target-1 $selector] == S } {
if [check-flags $args] {
upvar dg-do-what dg-do-what
set dg-do-what [list [lindex ${dg-do-what} 0] S F]
@@ -442,7 +442,7 @@
set args [lreplace $args 0 0]
if { [llength $args] 1 } {
set selector [list target [lindex $args 1]]
- if { [dg-process-target $selector] == S } {
+ if { [dg-process-target-1 $selector] == S } {
# The target matches, now check the flags.
if [check-flags $args] {
set shouldfail 1
@@ -457,16 +457,19 @@
# support use of an effective-target keyword in place of a list of
# target triplets to xfail or skip a test.
#
-# selector is one of:
-#xfail target-triplet-1 ...
-#xfail effective-target-keyword
-#xfail selector-expression
-#target target-triplet-1 ...
-#target effective-target-keyword
-#target selector-expression
+# The argument to dg-process-target is the keyword target or xfail
+# followed by a selector:
+#target-triplet-1 ...
+#effective-target-keyword
+#selector-expression
#
# For a target list the result is S if the target is selected, N otherwise.
# For an xfail list the result is F if the target is affected, P otherwise.
+
+# In contexts that allow either target or xfail
Re: [Test] Fix for PRPR53981
On 07/20/2012 05:23 AM, Anna Tikhonova wrote: Hi all, I've fixed test which was failing on Android NDK testsuite/ChangeLog: 2012-07-20 Anna Tikhonova anna.m.tikhon...@gmail.com * gcc.dg/20020201-1.c: Include stdlib.h. Patch attached. Ok for trunk 4.7? OK if you remove the declarations for abort, exit, rand, and srand; they're no longer needed. Presumably an alternate fix would be to add extern before the declarations of rand and srand. Janis
Re: [testsuite] backport cleanups to 4.7
On 07/06/2012 11:27 AM, Janis Johnson wrote: Between June 12 and June 28 I checked in lots of GCC testsuite patches to individual tests and to test infrastrure files to eliminate non-unique lines in test summaries, as well as a few related cleanups. May I backport those to GCC 4.7? It's been pointed out that I'm once again a testsuite maintainer and can make this decision myself. I'll be backporting the cleanups to the 4.7 branch soon. Janis
