aboutsummaryrefslogtreecommitdiff
path: root/gcc/gimple-array-bounds.cc
diff options
context:
space:
mode:
authorJakub Jelinek <jakub@redhat.com>2021-03-18 16:11:46 +0100
committerJakub Jelinek <jakub@redhat.com>2021-03-18 16:11:46 +0100
commitfff9faa79043aa53d361e7f6e31b2680007a97e2 (patch)
tree24688ba7bf2041a984c27035362fba70fa3f0970 /gcc/gimple-array-bounds.cc
parentd186c677e4fed6c58c46a6ea4dad9ee0fc9f31f1 (diff)
downloadgcc-fff9faa79043aa53d361e7f6e31b2680007a97e2.zip
gcc-fff9faa79043aa53d361e7f6e31b2680007a97e2.tar.gz
gcc-fff9faa79043aa53d361e7f6e31b2680007a97e2.tar.bz2
testsuite: Fix up strlenopt-73.c on powerpc [PR99626]
As mentioned in the testcase as well as in the PR, this testcase relies on MOVE_MAX being sufficiently large that the memcpy call is folded early into load + store. Some popular targets define MOVE_MAX to 8 or even 16 (e.g. x86_64 or some options on s390x), but many other targets define it to just 4 (e.g. powerpc 32-bit), or even 2. The testcase has already one test routine guarded on one particular target with MOVE_MAX 16 (but does it incorrectly, __i386__ is only defined on 32-bit x86 and __SIZEOF_INT128__ is only defined on 64-bit targets), this patch fixes that, and guards another test that relies on memcpy (, , 8) being folded that way (which therefore needs MOVE_MAX >= 8) on a couple of common targets that are known to have such MOVE_MAX. 2021-03-18 Jakub Jelinek <jakub@redhat.com> PR testsuite/99626 * gcc.dg/strlenopt-73.c: Ifdef out test_copy_cond_unequal_length_i64 on targets other than x86, aarch64, s390 and 64-bit powerpc. Use test_copy_cond_unequal_length_i128 for __x86_64__ with int128 support rather than __i386__.
Diffstat (limited to 'gcc/gimple-array-bounds.cc')
0 files changed, 0 insertions, 0 deletions