[llvm-bugs] [Bug 47400] New: constexpr variables in Lambda not known in Debug Info
via llvm-bugs
llvm-bugs at lists.llvm.org
Wed Sep 2 11:32:01 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=47400
Bug ID: 47400
Summary: constexpr variables in Lambda not known in Debug Info
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: melanie.blower at intel.com
CC: blitzrakete at gmail.com, dgregor at apple.com,
erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
richard-llvm at metafoo.co.uk
Within the lambda body, nothing is known about the constexpr identifier
Small example:
#define MAX_N_STEPS 8192
int main() {
constexpr int n_steps = MAX_N_STEPS + 2;
auto F = [=](unsigned int param) {
for (short i = n_steps; i >= 0; --i)
param += i;
};
F(42);
return 0;
}
gcc does produce information about the identifier, tho' the value is not
available (optimized out)
(gdb) b 6
Breakpoint 1 at 0x40111a: file test.cpp, line 6.
(gdb) r
Starting program: a.out.g++
Breakpoint 1, <lambda(unsigned int)>::operator()(unsigned int) const (
__closure=0x7fffffff96eb, param=42) at test.cpp:6
6 param += i;
(gdb) whatis n_steps
type = const int
However, if you build with clang the identifier isn't available
(gdb) whatis n_steps
No symbol "n_steps" in current context.
Debugger engineer at Intel recommended that the debug info could be emitted as
if the test program were written this way:
#define MAX_N_STEPS 8192
class lambda {
private:
static constexpr int n_steps = MAX_N_STEPS + 2;
public:
void operator() (unsigned int param) {
for (short i = n_steps; i >= 0; --i)
param += i;
}
};
int main() {
constexpr int n_steps = MAX_N_STEPS + 2;
lambda F;
F(42);
return 0;
}
My colleague at Intel Mike Rice wrote up an exploratory patch, I will link it
to this bug report. Hoping to get some feedback from debug info experts.
Thanks and regards --Melanie Blower
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200902/8efa38d0/attachment.html>
More information about the llvm-bugs
mailing list