On 22 April 2016 at 17:38, Bin.Cheng <amker.ch...@gmail.com> wrote: > On Fri, Apr 22, 2016 at 4:26 PM, Christophe Lyon > <christophe.l...@linaro.org> wrote: >> On 21 April 2016 at 11:03, Richard Biener <richard.guent...@gmail.com> wrote: >>> On Wed, Apr 20, 2016 at 5:08 PM, Bin Cheng <bin.ch...@arm.com> wrote: >>>> Hi, >>>> As reported in PR70715, GCC failed to prove no-overflows of IV(&p[n]) for >>>> simple example like: >>>> int >>>> foo (char *p, unsigned n) >>>> { >>>> while(n--) >>>> { >>>> p[n]='A'; >>>> } >>>> return 0; >>>> } >>>> Actually, code has already been added to handle this form loops when >>>> fixing PR68529. Problem with this case is loop niter analyzer records >>>> control_IV with its base expanded by calling expand_simple_operations. >>>> This patch simply adds code expanding BASE before we check its equality >>>> against control_IV.base. In the long run, we might want to remove the use >>>> of expand_simple_operations. >>>> >>>> Bootstrap and test on x86_64. Is it OK? >>> >> >> Hi Bin, >> >> On ARM and AArch64 bare-metal toolchains, this causes >> >> FAIL: gcc.dg/tree-ssa/minmax-2.c scan-tree-dump optimized "__builtin_fmin" > Hi Christophe, > As Kyrill pointed out, it doesn't look likely. The case doesn't even > have a loop for the patch to apply? >
Ha, you are right, sorry for the noise. I've had a lot of infrastructure problems these days with many build failures, introducing noise in the results :( Christophe > Thanks, > bin >> >> Christophe >> >>> Ok. >>> >>> Richard. >>> >>>> Thanks, >>>> bin >>>> >>>> >>>> 2016-04-20 Bin Cheng <bin.ch...@arm.com> >>>> >>>> PR tree-optimization/70715 >>>> * tree-ssa-loop-niter.c (loop_exits_before_overflow): Check >>>> equality >>>> after expanding BASE using expand_simple_operations.