[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)
>
>
Sorry, just realized I didn't explain the pseudocode. The real code looks
like this:

   int b = 0;
   struct foo {
     operator bool() { return ++b % 2; }
     ~foo() {}
   };
   void func() {}
   int x[] = {1, 2, 3};
   for (int a : x)
     if (foo f = foo())

So the loop runs 3 times, the condition goes true, false, true, and there's
a dtor at the end of the 'if' (but not the end of the loop or anything
else).

My attempts to actually change Clang to produce line zero, even while
disabling the integrated assembler, are incomplete - so far they've also
caused other instructions to end up at line zero, so I haven't nailed it
down entirely... - hence the asm hacking to get clear results for now.

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/56e3f6dd/attachment.html>