[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||jakub at gcc dot gnu.org Summary|[14 Regression] GCC, ICE: |[14 Regression] GCC, ICE: |internal compiler error: in |internal compiler error: in |verify_range, at|verify_range, at |value-range.cc:1104 |value-range.cc:1104 since ||r14-255 --- Comment #3 from Jakub Jelinek --- Started with r14-255-g04e5ddf8a313e85348a05c27708c845cc45e2e83 Aldy, do you think you could have a look?
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Aldy Hernandez --- (In reply to wierton from comment #0) > The testing program: > ``` > typedef long unsigned int size_t; > void *memcpy(void *, const void *, size_t); > int snprintf(char *restrict, size_t, const char *restrict, ...); > > extern char a[2]; > void test_func_on_line_62(void) { > memcpy(a, "12", sizeof("12") - 1); > const int res = snprintf(0, 0, "%s", a); > if (res <= 3) > do { > extern void f(void); > f(); > } while (0); > } The sprintf pass is ICEing because it's trying to build a nonsensical range of [2,1]. Legacy irange tried harder with swapped ranges, but in the above case it would actually drop to VARYING: - /* There's one corner case, if we had [C+1, C] before we now have -that again. But this represents an empty value range, so drop -to varying in this case. */ Which would cause the sprintf pass to set a global range of VARYING. I can't remember whether this meant nuking the known global range, or ignoring it altogether (the semantics changed in the last release or two). My guess is the later, since set_range_info() improves ranges, never pessimizes them. Now the reason we're passing swapped endpoints seems to originate in get_range_strlen_dynamic(). It is setting a min of 2, courtesy of the nonzero characters in the memcpy: memcpy(a, "12", sizeof("12") - 1); This comes from tree-ssa-strlen.c: if (!pdata->minlen && si->nonzero_chars) { if (TREE_CODE (si->nonzero_chars) == INTEGER_CST) pdata->minlen = si->nonzero_chars; Further down we set a max of 1, stemming from the size of a[2] minus 1 for the terminating null: if (TREE_CODE (size) == INTEGER_CST) { ++off; /* Increment for the terminating nul. */ tree toffset = build_int_cst (size_type_node, off); pdata->maxlen = fold_build2 (MINUS_EXPR, size_type_node, size, toffset); pdata->maxbound = pdata->maxlen; } I don't understand this code enough to opine, but at the worst we could bail if the ends are swapped. It's no worse than what we had before.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Jakub Jelinek changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #4) > Now the reason we're passing swapped endpoints seems to originate in > get_range_strlen_dynamic(). It is setting a min of 2, courtesy of the > nonzero characters in the memcpy: > > memcpy(a, "12", sizeof("12") - 1); Guess in a program without UB both the bounds are valid, a zero terminated string in char[2] array can't have strlen longer than 1 and when '1' and '2' characters are memcpyed at the start of some buffer then the string length will be at least 2. But the program would invoke UB if this code is reached, so the question is how to resolve it. The old behavior of VRP/ranger with swapping the boundaries avoided the ICE but wasn't right, this case isn't that the string length will be in [1, 2] range, but that the argument will never be a valid zero terminated string. So, guess either we shouldn't set minlen or maxlen (whatever is found second) if it violates the other bound, or check it after the fact and pick just one of them or set the other to one of them.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 57238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57238&action=edit gcc14-pr110603.patch Untested fix.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b338fdbc2b74f25c07da263a1f5983421fac1a53 commit r14-8487-gb338fdbc2b74f25c07da263a1f5983421fac1a53 Author: Jakub Jelinek Date: Mon Jan 29 10:20:32 2024 +0100 tree-ssa-strlen: Fix pdata->maxlen computation [PR110603] On the following testcase we emit an invalid range of [2, 1] due to UB in the source. Older VRP code silently swapped the boundaries and made [1, 2] range out of it, but newer code just ICEs on it. The reason for pdata->minlen 2 is that we see a memcpy in this case setting both elements of the array to non-zero value, so strlen (a) can't be smaller than 2. The reason for pdata->maxlen 1 is that in char a[2] array without UB there can be at most 1 non-zero character because there needs to be '\0' termination in the buffer too. IMHO we shouldn't create invalid ranges like that and even creating for that case a range [1, 2] looks wrong to me, so the following patch just doesn't set maxlen in that case to the array size - 1, matching what will really happen at runtime when triggering such UB (strlen will be at least 2, perhaps more or will crash). This is what the second hunk of the patch does. The first hunk fixes a fortunately harmless thinko. If the strlen pass knows the string length (i.e. get_string_length function returns non-NULL), we take a different path, we get to this only if all we know is that there are certain number of non-zero characters but we don't know what it is followed with, whether further non-zero characters or zero termination or either of that. If we know exactly how many non-zero characters it is, such as char a[42]; ... memcpy (a, "01234567890123456789", 20); then we take an earlier if for the INTEGER_CST case and set correctly just pdata->minlen to 20 in that case, but if we have something like int len; ... if (len < 15 || len > 32) return; memcpy (a, "0123456789012345678901234567890123456789", len); then we have [15, 32] range for the nonzero_chars and we set pdata->minlen correctly to 15, but incorrectly set also pdata->maxlen to 32. That is not what the above implies, it just means that in some cases we know that there are at least 32 non-zero characters, followed by something we don't know. There is no guarantee that there is '\0' right after it, so it means nothing. The reason this is harmless, just confusing, is that the code a few lines later fortunately overwrites this incorrect pdata->maxlen value with something different (either array length - 1 or all ones etc.). 2024-01-29 Jakub Jelinek PR tree-optimization/110603 * tree-ssa-strlen.cc (get_range_strlen_dynamic): Remove incorrect setting of pdata->maxlen to vr.upper_bound (which is unconditionally overwritten anyway). Avoid creating invalid range with minlen larger than maxlen. Formatting fix. * gcc.c-torture/compile/pr110603.c: New test.
[Bug tree-optimization/110603] [14 Regression] GCC, ICE: internal compiler error: in verify_range, at value-range.cc:1104 since r14-255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.