This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to fix PR65648



On 13/04/15 15:10, Yvan Roux wrote:
On 13 April 2015 at 15:42, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote:
On 09/04/15 12:10, Yvan Roux wrote:
diff --git a/gcc/testsuite/gcc.target/arm/pr65648.c
b/gcc/testsuite/gcc.target/arm/pr65648.c
new file mode 100644
index 0000000..e075546
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr65648.c
@@ -0,0 +1,9 @@
+/* { dg-do run } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
"-march=*" } { "-march=armv6" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-* } { "-marm"
} { "" } } */
+/* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } {
"*" } { "" } } */
+/* { dg-options "-mthumb -Os -mfloat-abi=soft" } */
+/* { dg-add-options arm_arch_v6 } */
+
+#include "../../gcc.c-torture/execute/pr65648.c"
+
Hi Yvan,

These are always tough to get right.
How about:
/* { dg-skip-if "avoid conflicting multilib options" { *-*-*eabihf } { "*" }
{ "" } } */
/* { dg-options "-Os -mthumb -mfloat-abi=soft" } */
/* { dg-add-options arm_arch_v6 } */
/* { dg-require-effective-target arm_arch_v6_ok } */
?

I think  the dg-skip-if will avoid the error when testing
arm-none-linux-gnueabihf:
  "error: ./pr65648.exe uses VFP register arguments, /tmp/ccXpRQ41.o does
not"

The dg-require-effective-target should remove the need for the first
dg-skip-if in your options.
I don't think it's worth skipping the test when the user explicitly asks for
-marm. It won't test the
behaviour of the bug but then again, the user overrode the options, so
presumably knows best.
Yes it looks better to me, the -marm skipping in my patch was an
artifact of testing it for armv6-m

Is there any case where this fails?
none that I can think of,  Is it ok to commit after I've re-tested it
(maybe once 5.1 is released) ?

Yes, the arm part is ok. I believe Jakub ok'ed the gcc.c-torture hunk.
I think it can go in now, as it is a testcase for a PR that was fixed for GCC 5.
Does it need to be committed to the release branch as well?

Thanks,
Kyrill


Yvan



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]