llvm-project/clang/test/CodeGenCXX/debug-info-scope.cpp

73 lines
2.9 KiB
C++
Raw Normal View History

// RUN: %clang_cc1 -debug-info-kind=limited -std=c++11 -emit-llvm %s -o -| FileCheck %s
//
// Two variables with the same name in subsequent if staments need to be in separate scopes.
//
// rdar://problem/14024005
int src();
void f();
void func() {
// CHECK: = !DILocalVariable(name: "i"
// CHECK-SAME: scope: [[IF1:![0-9]*]]
// CHECK-SAME: line: [[@LINE+2]]
// CHECK: [[IF1]] = distinct !DILexicalBlock({{.*}}line: [[@LINE+1]])
if (int i = src())
f();
// CHECK: = !DILocalVariable(name: "i"
// CHECK-SAME: scope: [[IF2:![0-9]*]]
// CHECK-SAME: line: [[@LINE+2]]
// CHECK: [[IF2]] = distinct !DILexicalBlock({{.*}}line: [[@LINE+1]])
if (int i = src()) {
f();
} else
f();
// CHECK: = !DILocalVariable(name: "i"
// CHECK-SAME: scope: [[FOR:![0-9]*]]
// CHECK-SAME: line: [[@LINE+2]]
// CHECK: [[FOR]] = distinct !DILexicalBlock({{.*}}line: [[@LINE+1]])
for (int i = 0;
// CHECK: = !DILocalVariable(name: "b"
// CHECK-SAME: scope: [[FOR_BODY:![0-9]*]]
// CHECK-SAME: line: [[@LINE+6]]
// CHECK: [[FOR_BODY]] = distinct !DILexicalBlock({{.*}}line: [[@LINE-4]])
// The scope could be located at 'bool b', but LLVM drops line information for
// scopes anyway, so it's not terribly important.
// FIXME: change the debug info schema to not include locations of scopes,
// since they're not used.
bool b = i != 10; ++i)
f();
// CHECK: = !DILocalVariable(name: "i"
// CHECK-SAME: scope: [[FOR:![0-9]*]]
// CHECK-SAME: line: [[@LINE+2]]
// CHECK: [[FOR]] = distinct !DILexicalBlock({{.*}}line: [[@LINE+1]])
for (int i = 0; i != 10; ++i) {
Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits). Several pieces of code were relying on implicit debug location setting which usually lead to incorrect line information anyway. So I've fixed those (in r225955 and r225845) separately which should pave the way for this commit to be cleanly reapplied. The reason these implicit dependencies resulted in crashes with this patch is that the debug location would no longer implicitly leak from one place to another, but be set back to invalid. Once a call with no/invalid location was emitted, if that call was ever inlined it could produce invalid debugloc chains and assert during LLVM's codegen. There may be further cases of such bugs in this patch - they're hard to flush out with regression testing, so I'll keep an eye out for reports and investigate/fix them ASAP if they come up. Original commit message: Reapply "DebugInfo: Generalize debug info location handling" Originally committed in r224385 and reverted in r224441 due to concerns this change might've introduced a crash. Turns out this change fixes the crash introduced by one of my earlier more specific location handling changes (those specific fixes are reverted by this patch, in favor of the more general solution). Recommitted in r224941 and reverted in r224970 after it caused a crash when building compiler-rt. Looks to be due to this change zeroing out the debug location when emitting default arguments (which were meant to inherit their outer expression's location) thus creating call instructions without locations - these create problems for inlining and must not be created. That is fixed and tested in this version of the change. Original commit message: This is a more scalable (fixed in mostly one place, rather than many places that will need constant improvement/maintenance) solution to several commits I've made recently to increase source fidelity for subexpressions. This resetting had to be done at the DebugLoc level (not the SourceLocation level) to preserve scoping information (if the resetting was done with CGDebugInfo::EmitLocation, it would've caused the tail end of an expression's codegen to end up in a potentially different scope than the start, even though it was at the same source location). The drawback to this is that it might leave CGDebugInfo out of sync. Ideally CGDebugInfo shouldn't have a duplicate sense of the current SourceLocation, but for now it seems it does... - I don't think I'm going to tackle removing that just now. I expect this'll probably cause some more buildbot fallout & I'll investigate that as it comes up. Also these sort of improvements might be starting to show a weakness/bug in LLVM's line table handling: we don't correctly emit is_stmt for statements, we just put it on every line table entry. This means one statement split over multiple lines appears as multiple 'statements' and two statements on one line (without column info) are treated as one statement. I don't think we have any IR representation of statements that would help us distinguish these cases and identify the beginning of each statement - so that might be something we need to add (possibly to the lexical scope chain - a scope for each statement). This does cause some problems for GDB and possibly other DWARF consumers. llvm-svn: 225956
2015-01-14 15:38:27 +08:00
// FIXME: Do not include scopes that have only other scopes (and no variables
// or using declarations) as direct children, they just waste
// space/relocations/etc.
// CHECK: [[FOR_LOOP_INCLUDING_COND:!.*]] = distinct !DILexicalBlock(scope: [[FOR]],{{.*}} line: [[@LINE-4]])
// CHECK: = !DILocalVariable(name: "b"
// CHECK-SAME: scope: [[FOR_COMPOUND:![0-9]*]]
// CHECK-SAME: line: [[@LINE+2]]
// CHECK: [[FOR_COMPOUND]] = distinct !DILexicalBlock(scope: [[FOR_LOOP_INCLUDING_COND]],{{.*}} line: [[@LINE-8]])
bool b = i % 2;
}
int x[] = {1, 2};
// CHECK: = !DILocalVariable(name: "__range1"
// CHECK-SAME: scope: [[RANGE_FOR:![0-9]*]]
// CHECK-NOT: line:
// CHECK-SAME: ){{$}}
// CHECK: [[RANGE_FOR]] = distinct !DILexicalBlock({{.*}}, line: [[@LINE+1]])
for (int i : x) {
// CHECK: = !DILocalVariable(name: "i"
// CHECK-SAME: scope: [[RANGE_FOR_BODY:![0-9]*]]
// CHECK-SAME: line: [[@LINE-3]]
// CHECK: [[RANGE_FOR_BODY]] = distinct !DILexicalBlock(scope: [[RANGE_FOR]],{{.*}} line: [[@LINE-4]])
}
}