| Message ID | CAKdteOZYTkdjJ8wzgUNv=ujcDONVzw8XEcE3avXe6hJU34BD8g@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 20 September 2012 23:06, Christophe Lyon <christophe.lyon@linaro.org> wrote: > Hi, > > GCC for ARM does not support compiling in Thumb1 mode and > float-abi=hard. But it does not fail unless the program being > compiled actually contains a function with parameters and/or a return > value. > > This is a (minor) problem in the testsuite in some configurations. > > For instance, if I run the testsuite forcing -mthumb (via site.exp) > for a GCC configured for float-abi=hard, and a test uses > /* { dg-require-effective-target arm_arch_v6_ok } */ > /* { dg-add-options arm_arch_v6 } */ > > it won't be unresolved since effective-target arm_arch_v6_ok is successful. > > The attached patch adds a dummy function body in the test such that it fails. > > Another way of achieving the same result is by making sure that the > relevant tests use > arm_arch_v6_multilib > instead of > arm_arch_v6_ok > > even if the test is not intended to be executed. > > OK? [I'm not a maintainer] You could argue that as the test is checking for just ARMv6, but then uses ARMv6+VFPv2 features - and so it going wrong is to be expected :-). So other approaches could be to see what adding /* { dg-require-effective-target arm_vfp_ok } */ after dg-add-options achieves. If that doesn't work I would suggest you add an arm_arch_v6_vfp_v2_ok set of effective-targets instead of restricting the current arm_arch_v6 effective target. Thanks, Matt
On 21/09/12 09:47, Matthew Gretton-Dann wrote: > On 20 September 2012 23:06, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> Hi, >> >> GCC for ARM does not support compiling in Thumb1 mode and >> float-abi=hard. But it does not fail unless the program being >> compiled actually contains a function with parameters and/or a return >> value. >> >> This is a (minor) problem in the testsuite in some configurations. >> >> For instance, if I run the testsuite forcing -mthumb (via site.exp) >> for a GCC configured for float-abi=hard, and a test uses >> /* { dg-require-effective-target arm_arch_v6_ok } */ >> /* { dg-add-options arm_arch_v6 } */ >> >> it won't be unresolved since effective-target arm_arch_v6_ok is successful. >> >> The attached patch adds a dummy function body in the test such that it fails. >> >> Another way of achieving the same result is by making sure that the >> relevant tests use >> arm_arch_v6_multilib >> instead of >> arm_arch_v6_ok >> >> even if the test is not intended to be executed. >> >> OK? > > [I'm not a maintainer] > > You could argue that as the test is checking for just ARMv6, but then > uses ARMv6+VFPv2 features - and so it going wrong is to be expected > :-). > > So other approaches could be to see what adding > > /* { dg-require-effective-target arm_vfp_ok } */ > > after dg-add-options achieves. That the test never runs on a Thumb1 processor. Which slightly defeats the object of testing thumb1 code. > > If that doesn't work I would suggest you add an arm_arch_v6_vfp_v2_ok > set of effective-targets instead of restricting the current > arm_arch_v6 effective target. > > Thanks, > > Matt >
On 21 September 2012 10:47, Matthew Gretton-Dann <matthew.gretton-dann@linaro.org> wrote: > On 20 September 2012 23:06, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> Hi, >> >> GCC for ARM does not support compiling in Thumb1 mode and >> float-abi=hard. But it does not fail unless the program being >> compiled actually contains a function with parameters and/or a return >> value. >> >> This is a (minor) problem in the testsuite in some configurations. >> >> For instance, if I run the testsuite forcing -mthumb (via site.exp) >> for a GCC configured for float-abi=hard, and a test uses >> /* { dg-require-effective-target arm_arch_v6_ok } */ >> /* { dg-add-options arm_arch_v6 } */ >> >> it won't be unresolved since effective-target arm_arch_v6_ok is successful. >> >> The attached patch adds a dummy function body in the test such that it fails. >> >> Another way of achieving the same result is by making sure that the >> relevant tests use >> arm_arch_v6_multilib >> instead of >> arm_arch_v6_ok >> >> even if the test is not intended to be executed. >> >> OK? > > [I'm not a maintainer] > > You could argue that as the test is checking for just ARMv6, but then > uses ARMv6+VFPv2 features - and so it going wrong is to be expected > :-). > No: what I have in mind is a test that doesn't need VFP by itself, but which happens to become not-compilable if one forces float-abi=hard and thumb when running the testsuite. I'd like that the test is UNSUPPORTED rather than FAIL. Christophe.
Hi Richard, On 21 September 2012 10:49, Richard Earnshaw <rearnsha@arm.com> wrote: > On 21/09/12 09:47, Matthew Gretton-Dann wrote: >> On 20 September 2012 23:06, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> Hi, >>> >>> GCC for ARM does not support compiling in Thumb1 mode and >>> float-abi=hard. But it does not fail unless the program being >>> compiled actually contains a function with parameters and/or a return >>> value. >>> >>> This is a (minor) problem in the testsuite in some configurations. >>> >>> For instance, if I run the testsuite forcing -mthumb (via site.exp) >>> for a GCC configured for float-abi=hard, and a test uses >>> /* { dg-require-effective-target arm_arch_v6_ok } */ >>> /* { dg-add-options arm_arch_v6 } */ >>> >>> it won't be unresolved since effective-target arm_arch_v6_ok is successful. >>> >>> The attached patch adds a dummy function body in the test such that it fails. >>> >>> Another way of achieving the same result is by making sure that the >>> relevant tests use >>> arm_arch_v6_multilib >>> instead of >>> arm_arch_v6_ok >>> >>> even if the test is not intended to be executed. >>> >>> OK? >> >> [I'm not a maintainer] >> >> You could argue that as the test is checking for just ARMv6, but then >> uses ARMv6+VFPv2 features - and so it going wrong is to be expected >> :-). >> >> So other approaches could be to see what adding >> >> /* { dg-require-effective-target arm_vfp_ok } */ >> >> after dg-add-options achieves. > > That the test never runs on a Thumb1 processor. Which slightly defeats > the object of testing thumb1 code. > I still have a test with /* { dg-require-effective-target arm_arch_v6_ok } */ /* { dg-add-options arm_arch_v6 } */ which fails when GCC is configured with --with-mode=thumb --target=arm-none-linuxgnueabihf Modifying check_effective_target_arm_arch_FUNC_ok as I suggested by including an empty function definition (as in check_effective_target_arm_arch_FUNC_multilib) suffices to turn the test into UNSUPPORTED rather than FAIL. What would you suggest instead? Thanks, Christophe.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index f597316..bc7d451 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -2211,6 +2211,11 @@ foreach { armfunc armflag armdef } { v4 "-march=armv4 -marm" __ARM_ARCH_4__ #if !defined (DEF) #error FOO #endif + int + main (void) + { + return 0; + } } "FLAG" ] } diff --git a/gcc/testsuite/gcc.target/arm/v6-ok.c b/gcc/testsuite/gcc.target/arm/v6-ok.c new file mode 100644 index 0000000..4eb1aed --- /dev/null +++ b/gcc/testsuite/gcc.target/arm/v6-ok.c @@ -0,0 +1,8 @@ +/* Check that compiling for armv6 is OK. This is useful to detect + configurations leading to thumb1 and float-abi=hard, which are not + supported currently. */ +/* { dg-do compile } */ +/* { dg-require-effective-target arm_arch_v6_ok } */ +/* { dg-add-options arm_arch_v6 } */ + +int func(void) { return 0; }
Hi, GCC for ARM does not support compiling in Thumb1 mode and float-abi=hard. But it does not fail unless the program being compiled actually contains a function with parameters and/or a return value. This is a (minor) problem in the testsuite in some configurations. For instance, if I run the testsuite forcing -mthumb (via site.exp) for a GCC configured for float-abi=hard, and a test uses /* { dg-require-effective-target arm_arch_v6_ok } */ /* { dg-add-options arm_arch_v6 } */ it won't be unresolved since effective-target arm_arch_v6_ok is successful. The attached patch adds a dummy function body in the test such that it fails. Another way of achieving the same result is by making sure that the relevant tests use arm_arch_v6_multilib instead of arm_arch_v6_ok even if the test is not intended to be executed. OK? Christophe. 2012-09-21 Christophe Lyon <christophe.lyon@linaro.org> gcc/testsuite: * lib/target-supports.exp (check_effective_target_arm_arch_FUNC_ok): Add function body to force error messages in some configurations. * gcc.target/arm/v6-ok.c: New test.