On Thu, Jun 11, 2015 at 12:38 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > Hi, > > On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote: >> >> IMHO the >> #if 0 >> #endif >> stuff doesn't belong to the patch. >> > > I just wanted to leave a hint, how I debugged this function, and how > to assess the performance of the decision that is taken here. > > I mean, the boot-strap would certainly pass, if I always return 0 here, > but Eric would'nt like it. > > I believe that, when the offset lies within the bounds that are implied by > the current function's stack frame, the access will always be safe. > > But there are some very rare false positives, when this function returns 0 > on "normal" code, like gcc source code itself, and they are interesting to > debug. > > Should I better change the #if 0 block into a comment?
Yes. If you have testcases for those rare false positives it would be nice to reduce them and at least archieve them in bugzilla. > >> Other than that, as I said already in the PR, I'm in favor of applying it to >> the trunk (only, not release branches) and watching for performance and/or >> wrong-code issues, but Eric is against it. What do others think about it? >> >> From John Regehr's talk at GCC Summit a few years ago I got the >> impression that for people to be able to effectively report bugs in the >> compiler through code generator it is important that discovered bugs in the >> compiler are fixed timely, otherwise it makes life to the reporters much >> harder, because then they'll run into the same still unfixed issue all the >> time. >> > > On that, I totally agree. I also think we need to be conservative. I didn't look at the patch in detail to check whether we are indeed conservative here (what about offsets that are not visibly constant like for if (n > m) ... a[m];?). Richard. > > Thanks > Bernd. >
