aboutsummaryrefslogtreecommitdiff
path: root/gcc/tree-vect-loop.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2017-08-16 00:42:23 +0100
committerJoseph Myers <jsm28@gcc.gnu.org>2017-08-16 00:42:23 +0100
commitaaf46c35d38b85342076e6c07f9a13afd598a38d (patch)
tree01bb4b9c7a8279f28e5be23b7a59629bf0c42da9 /gcc/tree-vect-loop.c
parent6b789c7f5aa91ef23d8b41e564cc30cc87b77d4c (diff)
downloadgcc-aaf46c35d38b85342076e6c07f9a13afd598a38d.zip
gcc-aaf46c35d38b85342076e6c07f9a13afd598a38d.tar.gz
gcc-aaf46c35d38b85342076e6c07f9a13afd598a38d.tar.bz2
Limit SH strncmp inline expansion (PR target/78460).
GCC mainline built for sh4-linux-gnu runs out of memory building a glibc test, which calls strncmp with very large constant size argument, resulting in the SH inline strncmp expansion trying to inline a fully unrolled expansion of strncmp for that size. This patch limits that fully unrolled expansion to the case of less than 32 bytes. This is explicitly *not* trying to be optimal in any way (very likely a lower threshold makes sense), just to limit enough to avoid the out-of-memory issue in the glibc testsuite. I have *not* run the GCC testsuite for SH. I have verified that this allows the glibc testsuite to build OK, with both GCC mainline and GCC 7 branch (and that the included test builds quickly with patched GCC, runs out of memory with unpatched GCC). PR target/78460 PR target/67712 gcc: * config/sh/sh-mem.cc (sh_expand_cmpnstr): Only unroll for constant count if that count is less than 32. gcc/testsuite: * gcc.c-torture/compile/string-large-1.c: New test. From-SVN: r251108
Diffstat (limited to 'gcc/tree-vect-loop.c')
0 files changed, 0 insertions, 0 deletions