[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 christophe.lyon at st dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from christophe.lyon at st dot com --- Fixed by r217707
[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #9) Hi, these tests are still failing. what are we gonna do about it? I am happy for a patch to delete them. Ramana
[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #11 from christophe.lyon at st dot com --- (In reply to Ramana Radhakrishnan from comment #10) (In reply to Bernd Edlinger from comment #9) Hi, these tests are still failing. what are we gonna do about it? I am happy for a patch to delete them. Ramana What about modifying the tests to use -O2 instead of -O0? At least, this would enable checking that the expected instruction is generated.
[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to christophe.lyon from comment #11) (In reply to Ramana Radhakrishnan from comment #10) (In reply to Bernd Edlinger from comment #9) Hi, these tests are still failing. what are we gonna do about it? I am happy for a patch to delete them. Ramana What about modifying the tests to use -O2 instead of -O0? At least, this would enable checking that the expected instruction is generated. Sure - patches welcome :)
[Bug target/61153] [ARM] vbic vorn tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hi, these tests are still failing. what are we gonna do about it?
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- These are caused by r210216 when those intrinsics were reimplemented in C rather than using builtins. The only reason they fail is because the tests are compiled with -O0 which prevents combine from matching the corresponding patterns. If compiled with optimisation the tests all work. I believe the plan is to remove these tests sometime soon anyway. See http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01836.html for more.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #2 from christophe.lyon at st dot com --- OK, but my tests currently don't inspect the generated code. They are execution tests, which means the could be PASS using only core instructions, and no Neon one. So maybe we should add some optimization level to the existing tests in the meantime?
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #3 from ktkachov at gcc dot gnu.org ---
So maybe we should add some optimization level to the existing tests in the
meantime?
Transforming them into something like
#include arm_neon.h
volatile int16x8_t arg0_int16x8_t;
volatile int16x8_t arg1_int16x8_t;
int16x8_t test_vbicQs16 (void)
{
int16x8_t out_int16x8_t;
return vbicq_s16 (arg0_int16x8_t, arg1_int16x8_t);
}
seems to work at -O2 (i.e. generates vbic and doesn't optimise away the whole
test), so it could be a way to go if the maintainers want it.
To be a bit pedantic, the ACLE spec doesn't strictly require the intrinsics
that the particular NEON instruction is generated, just that the functionality
is as defined in the spec (although the NEON instruction is likely to be the
optimal implementation of that functionality).
Do we plan to keep these scan-assembler tests? or go with just functional
tests?
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Since commit 210216 Neon intrinsics TLC - Replace intrinsics with GNU C implementations, I have noticed regressions in the following tests: gcc.target/arm/neon/vbicQs16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n Yes that is expected as per my original patch submission. Patch 1/3 said these tests would fail because at O0 combine doesn't run. I'm expecting your run time tests to go in and for cases where we need them, we may want to put out some kind of basic scan assembler tests for them. I'm tempted to mark this as invalid. with many --with-target/--with-cpu/--with-fpu configurations as can be seen on http://cbuild.validation.linaro.org/build/cross-validation/gcc/210216/report- build-info.html
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Do we plan to keep these scan-assembler tests? or go with just functional tests? No, not these scan assembler tests. They serve no purpose. I'm expecting them to get replaced by the testsuite you've been writing up and would like them to include any kind of scan-assembler tests if possible. Ramana
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #6 from christophe.lyon at st dot com --- (In reply to Ramana Radhakrishnan from comment #4) Yes that is expected as per my original patch submission. Patch 1/3 said these tests would fail because at O0 combine doesn't run. Indeed, sorry I forgot about it. I'm expecting your run time tests to go in and for cases where we need them, we may want to put out some kind of basic scan assembler tests for them. I'm tempted to mark this as invalid. How do we define cases where we need them? My concern is that some compiler change might cause a suboptimal-yet-functional code to be generated, and we wouldn't notice it.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #7 from christophe.lyon at st dot com --- (In reply to Ramana Radhakrishnan from comment #5) Do we plan to keep these scan-assembler tests? or go with just functional tests? No, not these scan assembler tests. They serve no purpose. I'm expecting them to get replaced by the testsuite you've been writing up and would like them to include any kind of scan-assembler tests if possible. Good suggestion, I'll look at how easily I can add that.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #8 from ramana.radhakrishnan at arm dot com ramana.radhakrishnan at arm dot com --- How do we define cases where we need them? My concern is that some compiler change might cause a suboptimal-yet-functional code to be generated, and we wouldn't notice it. Well, currently tests in gcc.target/arm/neon serve no functional / correctness purpose. The only thing they check is if the correct instruction is generated at O0 which is probably enough for that case. I would rather that we put in scan-assembler tests in your testsuite rather than anything else. regards Ramana
