[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from ktkachov at gcc dot gnu.org --- Fixed for GCC 8.
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Note that I posted this: https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01501.html ages ago :-)
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578 --- Comment #8 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Jan 18 09:30:58 2018 New Revision: 256840 URL: https://gcc.gnu.org/viewcvs?rev=256840&root=gcc&view=rev Log: [arm] PR target/65578: Fix builtin-bswap16-1.c and builtin-bswap-1.c The builtin-bswap-1.c and builtin-bswap16-1.c are pretty annoying at the moment. They force an explicit armv6 option that is a thumb1 target, so if you're testing a toolchain configured with something like --with-cpu=cortex-a15 --with-float=hard --with-mode=thumb you'll get those pesky errors about Thumb1 hard-float not being implemented, even though the tests don't relate to floating-point functionality at all. I *think* this is also due to the wrong order of dg-options and dg-require-effective-target directives that might end up not doing a proper effective target check. The solution in this patch is to commonise the code and create a couple of tests for each. One tests an armv6t2 target. This allows us to test an ARM or a Thumb2 target. The second one sets an armv6-m target, which is a Thumb1 target. The dg-add-options machinery for arm_arch_v6m knows how to add the right -mfloat-abi=soft option. With this patch we end up testing all of ARM, Thumb1, Thumb2 codegen whereas before we only ever tried testing Thumb1, if the multilib options happened to line up just right, and would give an ugly error otherwise. Now, if the multilib options don't allow the test it should just appear as UNSUPPORTED. PR target/65578 * gcc.target/arm/builtin-bswap.x: New file. * gcc.target/arm/builtin-bswap-1.c: Include the above. Add checks and options for armv6t2. * gcc.target/arm/builtin-bswap-2.c: Include the above. Add checks and options for Thumb1. * gcc.target/arm/builtin-bswap16.x: New file. * gcc.target/arm/builtin-bswap16-1.c: Include the above. Add checks and options for armv6t2. * gcc.target/arm/builtin-bswap16-2.c: Include the above. Add checks and options for Thumb1. Added: trunk/gcc/testsuite/gcc.target/arm/builtin-bswap-2.c trunk/gcc/testsuite/gcc.target/arm/builtin-bswap.x trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16-2.c trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16.x Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c trunk/gcc/testsuite/gcc.target/arm/builtin-bswap16-1.c
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578
--- Comment #7 from ktkachov at gcc dot gnu.org ---
(In reply to Tom de Vries from comment #1)
> Tightening the arm_arch_v6_ok test like this would fix the failure:
> ...
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index b57f545..75ca0a3 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2848,6 +2848,11 @@ foreach { armfunc armflag armdef } { v4 "-march=armv4
> -marm" __ARM_ARCH_4__
> #if !defined (DEF)
> #error !DEF
> #endif
> + int
> + f (void)
> + {
> + return 0;
> + }
> } "FLAG" ]
> }
>
> ...
Hi Tom,
Coming back to this, I think this is a good idea to do independently of the
builtin-bswap-1.c comments I made in comment #5.
I'm preparing a patch to refactor the builtin-bswap* tests to make them more
robust, but if you posted this patch to gcc-patches I'd approve it.
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578 --- Comment #6 from ktkachov at gcc dot gnu.org --- Also note that this test currently fails its scan-assembler check for -marm due to PR 67295
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578
--- Comment #5 from ktkachov at gcc dot gnu.org ---
These rev* instructions have both Thumb1 (16-bit) and Thumb2 as well as ARM
state forms and ideally we'd want to test them all.
Currently, the test is setup to only test the Thumb1 and ARM state generation
since it adds -march=armv6 which supports only Thumb1 and ARM state.
The Thumb1 codegen fails if the the toolchain is also configured for hard
float.
Adding -mfloat-abi=soft[fp] would fix the test but we wouldn't be testing the
generation of these instructions for Thumb2.
IMO this test tries to do to much in single file by conditionally scanning for
the conditional forms of the instructions depending on whether or not this is
thumb.
So I suggest bump the architecture required for this to arm_arch_v6t2 and
remove all the scan-assembler tests gated on { ! arm_nothumb } because now
Thumb2 will support the conditional forms (Thumb1 has no conditional
execution).
Then write a separate test that contains only the unconditional bswap calls and
compile that specifically for thumb1 i.e. for arm_arch_v6 with -mthumb and
-mfloat-abi=softfp and scan-assembler tests for the unconditional forms of the
rev* instructions.
What do you think?
[Bug target/65578] FAIL: gcc.target/arm/builtin-bswap-1.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65578 vries at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org Component|testsuite |target --- Comment #4 from vries at gcc dot gnu.org --- Kyrill, any ideas about this one? Adding -msoft-float or -marm allows builtin-bswap-1.c to pass. Given that the testcase has scan tests for arm_nothumb and ! arm_nothumb, should we add -msoft-float to the options? Or require soft-float? Thanks, - Tom
