[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) For h we get into the loop PHI handling code which drops to INF-1 if it iterates too much. The rest probably ripples down from that. I can't see where that [1, 0x7ff] issue happens. Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump: bb 2: g.0_9 = g; if (g.0_9 0) goto bb 3; else goto bb 9; bb 3: _12 = -g.0_9; i_13 = (long int) _12; goto bb 9; and Visiting statement: _12 = -g.0_25; Found new range for _12: [1, +INF(OVF)] marking stmt to be not simulated again Visiting statement: i_13 = (long int) _12; Found new range for i_13: [1, +INF(OVF)] marking stmt to be not simulated again The point was that the cast from 32-bit signed to 64-bit signed also should imply that the value is not bigger than INT_MAX, and that is what we would do if range for _12 was say [1, 0x7fff]. And for h, the point was that if only constants are assigned to the variable in a loop, then no matter how many iterations the loop has, the resulting value will only be one of the constants (thus smallest range covering those). Or in this particular case, as the h = 1 assignments is only in endless loop, we could have computed just [0, 0] (but that is probably too rare to care about).
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
I meant in the first loop.
But we handle:
int b, c, e;
long
foo (int x, int y)
{
long h = 0;
for (b = 0; b x; b++)
for (c = 0; c y; c++)
if (e)
h = 1;
return h + 4;
}
correctly, it is only as soon as one of those loops turns into endless loop:
int b, c, e;
long
foo (int x, int y)
{
long h = 0;
for (b = 0; b x; b++)
for (c = 0; c y;)
if (e)
h = 1;
return h + 4;
}
that we lose track. But, if it is only for endless loops, probably nothing to
worry about, the finite loops are much more important.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 28 Apr 2015, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) For h we get into the loop PHI handling code which drops to INF-1 if it iterates too much. The rest probably ripples down from that. I can't see where that [1, 0x7ff] issue happens. Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump: bb 2: g.0_9 = g; if (g.0_9 0) goto bb 3; else goto bb 9; bb 3: _12 = -g.0_9; i_13 = (long int) _12; goto bb 9; and Visiting statement: _12 = -g.0_25; Found new range for _12: [1, +INF(OVF)] marking stmt to be not simulated again Visiting statement: i_13 = (long int) _12; Found new range for i_13: [1, +INF(OVF)] marking stmt to be not simulated again The point was that the cast from 32-bit signed to 64-bit signed also should imply that the value is not bigger than INT_MAX, and that is what we would do if range for _12 was say [1, 0x7fff]. Yeah, but we _explicitely_ special-case the +INF(OVF) case in the source range assuming arbitrary overflow and thus use +INF(OVF) in the destination range as well. Probably for warnings or whatever (I don't like that OVF stuff anyway). And for h, the point was that if only constants are assigned to the variable in a loop, then no matter how many iterations the loop has, the resulting value will only be one of the constants (thus smallest range covering those). Or in this particular case, as the h = 1 assignments is only in endless loop, we could have computed just [0, 0] (but that is probably too rare to care about). But h also gets subtracted 1 as well. It is the PHI node h_2 = PHI 0(7), h_21(19) that causes the issue via the /* To prevent infinite iterations in the algorithm, derive ranges when the new value is slightly bigger or smaller than the previous one. We don't do this if we have seen a new executable edge; this helps us avoid an overflow infinity for conditionals which are not in a loop. If the old value-range was VR_UNDEFINED use the updated range and iterate one more time. */ if (edges 0 gimple_phi_num_args (phi) 1 edges == old_edges lhs_vr-type != VR_UNDEFINED) code as we go from Visiting PHI node: h_2 = PHI 0(7), h_21(19) Argument #0 (7 - 8 executable) 0: [0, 0] Argument #1 (19 - 8 executable) h_21: [0, 0] Meeting [0, 0] and [0, 0] to [0, 0] to Simulating statement (from ssa_edges): h_2 = PHI 0(7), h_21(19) Visiting PHI node: h_2 = PHI 0(7), h_21(19) Argument #0 (7 - 8 executable) 0: [0, 0] Argument #1 (19 - 8 executable) h_21: [0, 1] Meeting [0, 0] and [0, 1] to [0, 1] Intersecting [0, 9223372036854775806] and [-INF, +INF] to [0, 9223372036854775806] Found new range for h_2: [0, 9223372036854775806] as the range grows we drop to +INF - 1 (to give the next iteration the chance to compute wheter it will overflow - previously we dropped to +INF(OVF) immediately). Yes, we can do some more iterating or instead of dropping right away to +INF - 1 we could go towards +INF in log (+INF) steps. It's all a question about compile-time vs. accuracy in rare(?) cases. Yes, if we have a way to statically compute a good range estimate (like we try with adjust_range_with_scev) then that's of course even better. I don't see anything obvious here though.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) Created attachment 35395 [details] gcc5-pr65875.patch Untested fix. IMHO vrp_visit_phi_node was missing the vr_result VR_VARING handling if the value range turned into varying only during update_value_range, and also update_value_range wasn't telling the caller if it changed it into varying late. That said, the testcase has conditionally undefined variable, and checking whether all the VRP decisions (first and second pass) are sane, would be nice, Richard, could you please have a look? E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it really has just values 0 or 1, so should be ideally [0, 1]. Or that i has value range [1, LONG_MAX] - it is conditionally undefined (that is ignored), and conditionally negation of an int variable (only if that int variable is negative). The negated int variable is [1, +INF(OVF)] because INT_MIN might overflow, perhaps if we really need to preserve the OVF flag, we have to use [1, +INF(OVF)] again rather than just [1, 0x7fff] :(. For h we get into the loop PHI handling code which drops to INF-1 if it iterates too much. The rest probably ripples down from that. I can't see where that [1, 0x7ff] issue happens.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 27 12:21:17 2015 New Revision: 222461 URL: https://gcc.gnu.org/viewcvs?rev=222461root=gccview=rev Log: PR tree-optimization/65875 * tree-vrp.c (update_value_range): If in is_new case setting old_vr to VR_VARYING, also set new_vr to it. Remove old_vr-type == VR_VARYING test. (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of SSA_PROP_INTERESTING if update_value_range returned true, but new range is VR_VARYING. * gcc.c-torture/compile/pr65875.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr65875.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-vrp.c
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Apr 27 11:26:12 2015 New Revision: 222458 URL: https://gcc.gnu.org/viewcvs?rev=222458root=gccview=rev Log: PR tree-optimization/65875 * tree-vrp.c (update_value_range): If in is_new case setting old_vr to VR_VARYING, also set new_vr to it. Remove old_vr-type == VR_VARYING test. (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of SSA_PROP_INTERESTING if update_value_range returned true, but new range is VR_VARYING. * gcc.c-torture/compile/pr65875.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr65875.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
Summary|internal compiler error |[5/6 Regression] ICE:
|with gcc 5.1|Segmentation fault
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
int a, b, c, d, e, f, g;
void
fn1 ()
{
long h = 0, i;
if (g 0)
i = -g;
for (; b;)
for (; c;)
if (e)
h = 1;
for (; f;)
if (a)
break;
if (h i)
while (h i)
{
d = 0;
h--;
}
}
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35395 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35395action=edit gcc5-pr65875.patch Untested fix. IMHO vrp_visit_phi_node was missing the vr_result VR_VARING handling if the value range turned into varying only during update_value_range, and also update_value_range wasn't telling the caller if it changed it into varying late. That said, the testcase has conditionally undefined variable, and checking whether all the VRP decisions (first and second pass) are sane, would be nice, Richard, could you please have a look? E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it really has just values 0 or 1, so should be ideally [0, 1]. Or that i has value range [1, LONG_MAX] - it is conditionally undefined (that is ignored), and conditionally negation of an int variable (only if that int variable is negative). The negated int variable is [1, +INF(OVF)] because INT_MIN might overflow, perhaps if we really need to preserve the OVF flag, we have to use [1, +INF(OVF)] again rather than just [1, 0x7fff] :(.
