On 3/18/2021 8:35 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
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.
Tested on x86_64-linux and powerpc64-linux -m32/-m64, ok for trunk?
2021-03-18 Jakub Jelinek <ja...@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__.
OK with same comment as other patch.
Jeff
