Issue 122846
Summary `DILocation::getMergedLocation` produces invalid result while merging locations from `DILexicalBlockFile`
Labels wrong-debug, debuginfo
Assignees
Reporter asl
    Consider the following input:
```c
# 1 "1.c" 1
# 1 "1.c" 2
int foo(int a) {
  int i = 0;
  if ((a & 1) == 1) {
    a -= 1;
# 1 "m.c" 1
# 40 "m.c"
i += a;
i -= 10*a;
i *= a*a;
# 6 "1.c" 2
 } else {
    a += 3;
# 1 "m.c" 1
# 40 "m.c"
i += a;
i -= 10*a;
i *= a*a;
# 9 "1.c" 2
 }
  return i;
}
```

The LLVM IR looks like as follows:
```llvm
...
!10 = !DIFile(filename: "1.c", directory: "/Users/asl/Projects/llvm/build/bin")
...
!27 = !DIFile(filename: "m.c", directory: "/Users/asl/Projects/llvm/build/bin")
...
!39 = distinct !DILexicalBlock(scope: !20, file: !10, line: 6, column: 9)
!40 = !DILocation(line: 40, column: 6, scope: !41)
!41 = !DILexicalBlockFile(scope: !39, file: !27, discriminator: 0)
```

Note that here we're having two nested scopes from different files.

The resulting code looks like as:
```
        .loc    1 42 7 prologue_end is_stmt 1   ; 1.c:42:7
        mul     w9, w8, w8
        .loc    1 41 3                          ; 1.c:41:3
        mul     w8, w9, w8
Ltmp2:
        .loc    1 42 3                          ; 1.c:42:3
        add     w8, w8, w8, lsl #3
        neg     w0, w8
Ltmp3:
        ;DEBUG_VALUE: foo:i <- $w0
        .loc    1 10 3                          ; 1.c:10:3
        ret
```
and:
```llvm
!10 = !DIFile(filename: "1.c", directory: "/Users/asl/Projects/llvm/build/bin")
...
!19 = distinct !DILexicalBlock(scope: !9, file: !10, line: 3, column: 7)
...
!22 = !DILocation(line: 42, column: 7, scope: !19)
```
So, after merging we end with invalid location info: line numbers are from one file, but file itself is different – from enclosing scope.

Indeed, it seems that `DILocation::getMergedLocation` completely ignores possibility that file could be changed and recreates the scope with invalid location info. It already has the code that handles `inlinedAt`. It think `DILexicalBlockFile` should be treated in a same way as this is essentially "textual inclusion".
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to