'artificial' attribute marked function's debug location is not correct

[Fangqing2018]

https://lists.llvm.org/pipermail/llvm-dev/2022-January/154818.html

[dwblaikie]

I don't think this bug is correct - it seems like the bug is that the Clang documentation is incorrect, not that the behavior is incorrect.

Do you know of any cases where Clang's behavior differs from GCC's?

[Fangqing2018]

Hi David,

I don't know what's GCC's behavior, and I didn't do the comparison.
The issue comes out that during our development, sometimes we don't want user to refer to the already inlined library code, and we want the info/warning/error msg stops at the user's code.
And according to the doc from clang about 'aritificial', I think we can use this attribute for this kind of scenario (mark to-be-inlined function with 'artificial' attribute). But when we do this, we don't find the differences.
So I sent the email for confirmation.
If you believe it's just clang doc error, then feel free to ignore or close this issue.
Thanks,
Fangqing

[dwblaikie]

To be clear - this attribute is about how debug info works, which isn't relevant to how Clang diagnostics are generated.

If you're talking about info/warning/errors generated by clang - not wanting those to mention implementation details in templates, for instance, no matter how this attribute is implemented it wouldn't affect that. I don't think we have any tool to do that.

Can you describe in more detail the particular issue you're trying to address?

[Fangqing2018]

For example, if we have a lib function read like following:

inline int read(int Ptr) {
  return *Ptr;
}

And at user side, this lib function is called, but in a wrong way, let's say, somehow it passes a nullptr into the lib function read.

void user_func () {
  ...
  read(nullptr);
  ...
}

During transformation, we catch this null load instruction, and try to tell user there's a wrong memory access, at the same time, we need to tell user the location it happens. And in this case, since the root cause is from the callsite, but load instruction debug location points to the lib function. So when we dump the error msg, instead of dumping the location of call site, but the location of callee function, and this is not we want.

[dwblaikie]

OK, so you've got some 3rd party transformation that's producing user-facing errors on certain IR?

Sounds like the thing to do is to look through the DebugLoc locations - if the DIScope chain attached to the location is artificial, then use the inlinedAt location instead (repeat this as needed until you reach a DebugLoc that doesn't have a DIScope chain with an artificial DISubprogram. (that would work with the current artificial attribute support/behavior)

Alternatively you could use the nodebug attribute on such functions, that should probably produce the same behavior you want? (that would work with the current code you have for producing these diagnostics, I guess)

[Fangqing2018]

Yes, nodebug attribute sounds good enough for us.
Thank you, David, for your suggestion!