The analysis for nb_iterations_upper_bound is bogus when we derive bounds for
an exit check ptr == 0 (leading to an assert). The testcase looks like
(subroutine cxb3014__test_block__char_pointers__value from acats CXB3014):
<bb 5>:
# p_1 = PHI <ref_58(3), p_52(8)>
# h_2 = PHI <0(3), h_10(8)>
D.3266_7 = *p_1;
if (D.3266_7 == terminator_9(D))
goto <bb 9>;
else
goto <bb 6>;
<bb 6>:
h_10 = h_2 + 1;
if (p_1 == 0B)
goto <bb 7>;
else
goto <bb 8>;
<bb 7>:
D.3760.P_ARRAY = "i-cpoint.adb:59 instantiated at cxb3014.adb:114";
D.3760.P_BOUNDS = &*.LC15;
ada.exceptions.raise_exception_always (&char_pointers__pointer_error,
D.3760);
<bb 8>:
left.84_50 = (cxb3014__test_block__char_pointers__addr) p_13;
D.3762_51 = left.84_50 + 1;
p_52 = (cxb3014__test_block__char_pointers__element * {ref-all}) D.3762_51;
# DEBUG ref => p_52
# DEBUG p => p_52
goto <bb 5>;
<bb 9>:
...
when looking at the exit 6->7 number_of_iterations_ne is present with
iv->base (cxb3014__test_block__char_pointers__element * {ref-all}) ref_4(D)
and final 0B, the step is 1. We then do
else
{
s = fold_convert (niter_type, iv->step);
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, final),
fold_convert (niter_type, iv->base));
}
which creates -(UNSIGNED_64) ref_4(D) for c, with no_overflow set as we
do for pointers (but note we now have unsigned_type_for, a non-pointer!)
we obviously can't reach zero with a step of 1 without overflowing
without the initial value being zero.
I have a patch in the works that uses number of iteration analysis for
value-range propagation and that miscompiles CXB3014 because of the
above bug.
Zdenek - any idea?
--
Summary: Number of iteration analysis bogus
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
