Created attachment 40105 [details] preprocessed source GCC mainline built for sh4-linux-gnu runs out of memory building string/tst-cmp.c. The symptom observed is that cc1's memory usage goes up by a bit under 1GB a second until it's killed after exhausting memory and swap (on a system with 128GB of each). Compile with: sh4-glibc-linux-gnu-gcc -S tst-cmp.i -fno-isolate-erroneous-paths-dereference -fno-isolate-erroneous-paths-attribute -std=gnu11 -fgnu89-inline -O2 -fmerge-all-constants -g Preprocessed source attached.
Simple test-case: int foo(char *left, char *right) { return strncmp (left, right, 4294967295U); } triggers ICE after I added: diff --git a/gcc/config/sh/sh-mem.cc b/gcc/config/sh/sh-mem.cc index f91afa5..018d8bb 100644 --- a/gcc/config/sh/sh-mem.cc +++ b/gcc/config/sh/sh-mem.cc @@ -364,6 +364,7 @@ sh_expand_cmpnstr (rtx *operands) rtx_code_label *L_end_loop_long = gen_label_rtx (); int bytes = INTVAL (operands[3]); + gcc_assert (bytes >= 0); int witers = bytes / 4; if (witers > 1) Looks 'int' should be replaces with unsigned HOST_WIDE_INT, but still using a cross compiler, where host is x86_64, I get: (gdb) p debug_rtx(operands[3]) (const_int -1 [0xffffffffffffffff]) $1 = void and thus unsigned HOST_WIDE_INT bytes = INTVAL (operands[3]); is 18446744073709551615 (0xffffffffffffffff). Apart from that, I wondering why there's no limit, as for instance: strncmp (left, right, 1000); emits battalion of instructions.
(In reply to Martin Liška from comment #1) > > Apart from that, I wondering why there's no limit, as for instance: > strncmp (left, right, 1000); emits battalion of instructions. Oh yeah, that's PR 67712.
I see ~500 GiB with GCC 7.0.1 20170501 (prerelease) [gcc-7-branch revision 247430]. This interferes rather badly with cross-compiler-based testing.
FWIW, my build-many-glibcs.py bots for GCC 7 and mainline are run with "ulimit -v 16777216" to limit the effects of this bug.
GCC 7.1 has been released.
Author: jsm28 Date: Tue Aug 15 23:42:23 2017 New Revision: 251108 URL: https://gcc.gnu.org/viewcvs?rev=251108&root=gcc&view=rev Log: 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. Added: trunk/gcc/testsuite/gcc.c-torture/compile/string-large-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh-mem.cc trunk/gcc/testsuite/ChangeLog
Author: jsm28 Date: Tue Aug 15 23:43:11 2017 New Revision: 251109 URL: https://gcc.gnu.org/viewcvs?rev=251109&root=gcc&view=rev Log: 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. Added: branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/compile/string-large-1.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/sh/sh-mem.cc branches/gcc-7-branch/gcc/testsuite/ChangeLog
Fixed for GCC 7.3 and GCC 8.
Author: aldyh Date: Wed Sep 13 16:59:51 2017 New Revision: 252436 URL: https://gcc.gnu.org/viewcvs?rev=252436&root=gcc&view=rev Log: 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. Added: branches/range-gen2/gcc/testsuite/gcc.c-torture/compile/string-large-1.c Modified: branches/range-gen2/gcc/ChangeLog branches/range-gen2/gcc/config/sh/sh-mem.cc branches/range-gen2/gcc/testsuite/ChangeLog