[PATCH] PR19864: Revert r209764 in favor of the fix in r215766 (loop backedge jump attributed to confusing location when the last source line of a loop is inside a conditional)

[David Blaikie]

On Tue, Aug 26, 2014 at 1:45 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Mon, Aug 18, 2014 at 2:33 PM, Adrian Prantl <aprantl at apple.com> wrote:
> > IMO, the best we can do is to use the end of the CompoundStmt as the
> cleanup location if there is one, and otherwise give up and use line 0.
>
> OK. The "let's do better when there's braces" isn't something I'm worrying
> about for now - it's a possible incremental improvement after we figure out
> the "worst case" behavior.
>
>
> >
> > ```
> > if (c)
> >   foo(); // cleanups = line 0
> >
> > if (c) {
> > }         // cleanups
> >
> > if (c)
> >   foo();
> > else {
> >   bar();
> > }       // cleanups
>
> In this case, I'm not sure the close } to the else is any better than the
> last line of the else, it still feels like part of the else, not the end of
> the if scope.
>
> Anyway, using line zero (did this by hand and used no-integrated-as
> because Clang doesn't cope well with emitting line table entries for line
> 0) here's GDB's behavior in some examples:
>
> GCC is GCC 4.8
> ToT is Clang ToT
> End is this patch applied to Clang ToT to use the end of the if as the
> location
> Zer is the end patch applied, and then manually editing the assembly (and
> assembling with the system assembler, not the integrated assembler) to have
> the non-exceptional dtor call be on line 0.
>
> So we get the totally right behavior from GDB the same as we would by
> assigning it to the end. In the cases where we get different behavior, it's
> better - we don't step to lines that don't execute, but we still get a bad
> location walking up from the dtor call (end up wherever the preceeding code
> was - which means sometimes we end up on the last line of the function
> where the EH cleanup is ascribed to). Seems better, but not perfect. (but
> we have no way to get perfect)
>

& one other thing I didn't highlight was where the dtor was ascribed to in
GCC, ToT, and End. I guess ToT and End are clear - that's the whole
contention of this patch, ToT ascribes it to the 'if' (line 2 in all the
examples below) and End ascribes it to the end of the if (line N-1 in all
the examples below). GCC ascribes it to N-1 as well. As discussed
previously, the way to get Clang to do what GCC is doing, is to do 'End' as
well as moving the EH cleanup block after the normal cleanup. Then you get
the advantages (1 (even better than "Zero", since it gets the dtor location
'right') and 2 (same as "Zero")) and disadvantages (weird nexting behavior
in 3 and 4).


>
> 1:   for
> 2:     if
> 3:       func();
> 4: }
>
> GCC: 1 2 3 1 2 1 2 3 1 4
> ToT: 1 2 3 2 1 2 2 1 2 3 2 1 4
> End: 1 2 3 3 1 2 3 1 2 3 3 1 4
> Zer: 1 2 3 1 2 1 2 3 1 4, dtor skipped and ascribed to 4
>
> 1:   for
> 2:     if
> 3:       func();
> 4:     else
> 5:       func();
> 6: }
>
> GCC: 1 2 3 1 2 5 1 2 3 1 6
> ToT: 1 2 3 2 1 2 5 2 2 3 2 1 6
> End: 1 2 3 1 2 5 1 2 3 1 6
> Zer: 1 2 3 1 2 5 1 2 3 1 6, dtor skipped and ascribed to 5
>
> 1:   for
> 2:     if
> 3:       ;
> 4:     else
> 5:       ;
> 6: }
>
> GCC: 1 2 5 1 2 5 1 2 5 1 6
> ToT: 1 2 2 1 2 2 1 2 2 1 6
> End: 1 2 5 1 2 5 1 2 5 1 6
> Zer: 1 2 1 2 1 2 1 6, dtor skipped and ascribed to 6
>
> 1:   for
> 2:     if
> 3:       ;
> 4: }
>
> GCC: 1 2 3 1 2 3 1 2 3 1 4
> ToT: 1 2 2 1 2 2 1 2 2 1 4
> End: 1 2 3 1 2 3 1 2 3 1 4
> Zer: 1 2 1 2 1 2 1 4, dtor skipped and ascribed to 4
>
> > ```
> >
> > http://reviews.llvm.org/D4956
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140826/c4b8143a/attachment.html>