On Mon, Apr 8, 2013 at 3:07 PM, Adrian Prantl <[email protected]> wrote: > > Hi Eric, > > On Apr 8, 2013, at 1:23 PM, Eric Christopher <[email protected]> wrote: > >> So, since you didn't respond to the rest, these are the similar bugs I >> was speaking about: >> >> http://llvm.org/bugs/show_bug.cgi?id=14498 >> http://llvm.org/bugs/show_bug.cgi?id=14580 >> >> with a little bit due to: >> >> http://llvm.org/bugs/show_bug.cgi?id=14610 >> http://llvm.org/bugs/show_bug.cgi?id=14473 > > Great! I was hesitant to answer to the rest before I knew more about those > PRs :-) > >> >> Before we go forward with this I'd like to discuss the general >> applicability here for line information. > > Sure. My argument for the ARC case is that there is no sensible source line > to associate calls to ARC runtime functions (that are mostly transparent to > the programmer) with. > > For the ARC setup code it may be possible to use the location of the > beginning of the lexical scope. I’m not convinced about the cleanup part, > though. Do we really want to step through > > 1 void foo() { > 2 return 1; > 3 } > > in the order 1-3-2 ? (And right now it would be 3-2-3, which is even worse). > > The situation is perhaps less clear if the return statement is missing. > According to http://llvm.org/bugs/show_bug.cgi?id=14498, GCC does create an > entry for the last line, but at least the lines are visited consecutively. > (Is that also true if there is a complex expression in the return?)
Generally GCC seems to emit the return expression on the line its written, but the return instruction on the close }. > > My personal opinion would be to not emit line info if we don’t have anything > to point to in the source code -- it might even reduce the size of our debug > info. > Of course, not breaking the gdb testsuite would be a good argument against > it. I don’t think that this would be the case for ARC, though. > >> Few notes on the patch: > > I made all suggested changes, thanks for the review! > > -- Adrian _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
