http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- congh at google dot com <gcc-bugzi...@gcc.gnu.org> wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58686 > >--- Comment #2 from Cong Hou <congh at google dot com> --- >I think this issue is more like a missed optimization. > >If the iteration number can be calculated as a constant value at >compile time, >then the function assert_loop_rolls_lt() won't be called due to an >early exit >(specifically in the function number_of_iterations_lt() at the call to >number_of_iterations_lt_to_ne()). That is why I could not craft a >testcase >showing miscompile. > >A better test case is shown below: > > >#define N 4 >void foo(int* a, unsigned int i) >{ > int j = 0; > do > { > a[j++] = 0; > i -= 4; > } > while (i >= N); >} > > >Compile it with -O3 and the produced result is using __builtin_memset() >as the >niter can be calculated. But if the value of N is replaced by others >like 3 or >5, GCC won't optimize this loop into __builtin_memset() any more. Yeah, the issue in general is finding a condition that ensures the loop will terminate and a formula that computes the number of iterations if that holds true. In case of wrapping arithmetic this is non-trivial and likely not all cases are implemented. Richard.
