diff options
author | Jakub Jelinek <jakub@redhat.com> | 2021-03-18 16:11:46 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2021-03-18 16:11:46 +0100 |
commit | fff9faa79043aa53d361e7f6e31b2680007a97e2 (patch) | |
tree | 24688ba7bf2041a984c27035362fba70fa3f0970 /gcc/gimple-array-bounds.cc | |
parent | d186c677e4fed6c58c46a6ea4dad9ee0fc9f31f1 (diff) | |
download | gcc-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