[llvm] r297161 - Relax the conflicting function arg verifier to allow for inlined debug

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 7 11:19:18 PST 2017


Ah, I see - might be worth a comment in the test case to describe a bit
more about what it's aiming for?

& would this suffice?

void sink();
inline __attribute__((always_inline)) void f1(int) {
  sink();
}
void f2() {
  f1(0);
  f1(0);
}

(if that's not sufficient, then perhaps the verifier needs to be made
stronger to catch this case where they're actually different variables even
though they're represented by the same DILocalVariable? (two different
inlinings) - or I guess this case it got correct for free/accidentally
because it was the same variable object)

Anyway, all good (:

On Tue, Mar 7, 2017 at 11:00 AM Adrian Prantl <aprantl at apple.com> wrote:

On Mar 7, 2017, at 10:58 AM, David Blaikie <dblaikie at gmail.com> wrote:

Ah, it might be more obvious if one of 'f' or 'g' was left
standalone/non-inline, then? Or perhaps I'm not fully understanding the
conflict being tested for? Two args with the same name but different arg
objects in the same function?


The name is not relevant. The condition is two args with different
variables that both claim to be argNo: 1 and are not inlined.

-- adrian


OK, so I can see why that would require two inlinings, if that's the case.
Thanks for explaining!

On Tue, Mar 7, 2017 at 10:49 AM Adrian Prantl <aprantl at apple.com> wrote:

Because the outermost function is nodebug and we need at least two function
args to create a conflict.

-- adrian

On Mar 7, 2017, at 10:47 AM, David Blaikie <dblaikie at gmail.com> wrote:

Thanks! Any idea why it requires both 'f' and 'g' to reproduce this?

(& I imagine the return values probably aren't needed?)

On Tue, Mar 7, 2017 at 10:39 AM Adrian Prantl <aprantl at apple.com> wrote:

I replaced it with a smaller, hand-crafted testcase in r297176.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170307/5cbfb337/attachment.html>


More information about the llvm-commits mailing list