* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
@ 2015-04-24 12:29 ` trippels at gcc dot gnu.org
2015-04-24 16:37 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: trippels at gcc dot gnu.org @ 2015-04-24 12:29 UTC (permalink / raw)
To: gcc-bugs
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--;
}
}
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
2015-04-24 12:29 ` [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault trippels at gcc dot gnu.org
@ 2015-04-24 16:37 ` jakub at gcc dot gnu.org
2015-04-27 9:15 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-24 16:37 UTC (permalink / raw)
To: gcc-bugs
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=35395&action=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, 0x7fffffff] :(.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
2015-04-24 12:29 ` [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault trippels at gcc dot gnu.org
2015-04-24 16:37 ` jakub at gcc dot gnu.org
@ 2015-04-27 9:15 ` rguenth at gcc dot gnu.org
2015-04-27 11:26 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-27 9:15 UTC (permalink / raw)
To: gcc-bugs
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, 0x7fffffff] :(.
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, 0x7ffffff] issue happens.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (2 preceding siblings ...)
2015-04-27 9:15 ` rguenth at gcc dot gnu.org
@ 2015-04-27 11:26 ` jakub at gcc dot gnu.org
2015-04-27 12:21 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-27 11:26 UTC (permalink / raw)
To: gcc-bugs
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=222458&root=gcc&view=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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (3 preceding siblings ...)
2015-04-27 11:26 ` jakub at gcc dot gnu.org
@ 2015-04-27 12:21 ` jakub at gcc dot gnu.org
2015-04-27 12:29 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-27 12:21 UTC (permalink / raw)
To: gcc-bugs
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=222461&root=gcc&view=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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (4 preceding siblings ...)
2015-04-27 12:21 ` jakub at gcc dot gnu.org
@ 2015-04-27 12:29 ` jakub at gcc dot gnu.org
2015-04-28 7:51 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-27 12:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (5 preceding siblings ...)
2015-04-27 12:29 ` jakub at gcc dot gnu.org
@ 2015-04-28 7:51 ` jakub at gcc dot gnu.org
2015-04-28 8:16 ` rguenther at suse dot de
2015-04-28 8:28 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-28 7:51 UTC (permalink / raw)
To: gcc-bugs
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, 0x7ffffff] 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, 0x7fffffff].
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).
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (6 preceding siblings ...)
2015-04-28 7:51 ` jakub at gcc dot gnu.org
@ 2015-04-28 8:16 ` rguenther at suse dot de
2015-04-28 8:28 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenther at suse dot de @ 2015-04-28 8:16 UTC (permalink / raw)
To: gcc-bugs
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, 0x7ffffff] 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, 0x7fffffff].
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
2015-04-24 12:16 [Bug c/65875] New: internal compiler error with gcc 5.1 megahallon at gmail dot com
` (7 preceding siblings ...)
2015-04-28 8:16 ` rguenther at suse dot de
@ 2015-04-28 8:28 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-28 8:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread