RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-30 15:32:52 +01:00
Code Issues Projects Releases Wiki Activity
19930f378f
llvm-mirror/test/DebugInfo/X86/pr13303.ll

27 lines
1.6 KiB
LLVM
Raw Normal View History

Reapply r160148 (reverted in r163570) fixing spurious breakpoints in modern GDB This reapplies the fix for PR13303 now with more justification. Based on my execution of the GDB 7.5 test suite this results in: expected passes: 16101 -> 20890 (+30%) unexpected failures: 4826 -> 637 (-77%) There are 23 checks that used to pass and now fail. They are all in gdb.reverse. Investigating a few looks like they were accidentally passing due to extra breakpoints being set by this bug. They're generally due to the difference in end location between gcc and clang, the test suite is trying to set breakpoints on the closing '}' that clang doesn't associate with any instructions. llvm-svn: 169304
2012-12-04 22:05:36 +01:00
; RUN: llc %s -o %t -filetype=obj -mtriple=x86_64-unknown-linux-gnu
Now that llvm-dwarfdump supports flags to specify which DWARF section to dump, use them in tests that run llvm-dwarfdump. This is in order to make tests as specific as possible. llvm-svn: 173498
2013-01-25 22:44:53 +01:00
; RUN: llvm-dwarfdump -debug-dump=line %t | FileCheck %s
Reapply r160148 (reverted in r163570) fixing spurious breakpoints in modern GDB This reapplies the fix for PR13303 now with more justification. Based on my execution of the GDB 7.5 test suite this results in: expected passes: 16101 -> 20890 (+30%) unexpected failures: 4826 -> 637 (-77%) There are 23 checks that used to pass and now fail. They are all in gdb.reverse. Investigating a few looks like they were accidentally passing due to extra breakpoints being set by this bug. They're generally due to the difference in end location between gcc and clang, the test suite is trying to set breakpoints on the closing '}' that clang doesn't associate with any instructions. llvm-svn: 169304
2012-12-04 22:05:36 +01:00
; PR13303
; Check that the prologue ends with is_stmt here.
; CHECK: 0x0000000000000000 {{.*}} is_stmt
define i32 @main() nounwind uwtable {
entry:
%retval = alloca i32, align 4
store i32 0, i32* %retval
ret i32 0, !dbg !10
}
!llvm.dbg.cu = !{!0}
Revert "PR14606: debug info imported_module support" This reverts commit r179836 as it seems to have caused test failures. llvm-svn: 179840
2013-04-19 09:47:16 +02:00
!0 = metadata !{i32 786449, i32 12, metadata !6, metadata !"clang version 3.2 (trunk 160143)", i1 false, metadata !"", i32 0, metadata !1, metadata !1, metadata !3, metadata !1, metadata !""} ; [ DW_TAG_compile_unit ] [/home/probinson/PR13303.c] [DW_LANG_C99]
Remove the (apparently) unnecessary debug info metadata indirection. The main lists of debug info metadata attached to the compile_unit had an extra layer of metadata nodes they went through for no apparent reason. This patch removes that (& still passes just as much of the GDB 7.5 test suite). If anyone can show evidence as to why these extra metadata nodes are there I'm open to reverting this patch & documenting why they're there. llvm-svn: 174266
2013-02-02 06:56:24 +01:00
!1 = metadata !{i32 0}
!3 = metadata !{metadata !5}
Revert "Adding DIImportedModules to DIScopes." This reverts commit 342d92c7a0adeabc9ab00f3f0d88d739fe7da4c7. Turns out we're going with a different schema design to represent DW_TAG_imported_modules so we won't need this extra field. llvm-svn: 178215
2013-03-28 03:44:59 +01:00
!5 = metadata !{i32 786478, metadata !6, metadata !"main", metadata !"main", metadata !"", metadata !6, i32 1, metadata !7, i1 false, i1 true, i32 0, i32 0, null, i32 0, i1 false, i32 ()* @main, null, null, metadata !1, i32 1} ; [ DW_TAG_subprogram ] [line 1] [def] [main]
!6 = metadata !{i32 786473, metadata !"PR13303.c", metadata !"/home/probinson", null} ; [ DW_TAG_file_type ]
!7 = metadata !{i32 786453, i32 0, metadata !"", i32 0, i32 0, i64 0, i64 0, i64 0, i32 0, null, metadata !8, i32 0, i32 0} ; [ DW_TAG_subroutine_type ] [line 0, size 0, align 0, offset 0] [from ]
Reapply r160148 (reverted in r163570) fixing spurious breakpoints in modern GDB This reapplies the fix for PR13303 now with more justification. Based on my execution of the GDB 7.5 test suite this results in: expected passes: 16101 -> 20890 (+30%) unexpected failures: 4826 -> 637 (-77%) There are 23 checks that used to pass and now fail. They are all in gdb.reverse. Investigating a few looks like they were accidentally passing due to extra breakpoints being set by this bug. They're generally due to the difference in end location between gcc and clang, the test suite is trying to set breakpoints on the closing '}' that clang doesn't associate with any instructions. llvm-svn: 169304
2012-12-04 22:05:36 +01:00
!8 = metadata !{metadata !9}
Revert "Adding DIImportedModules to DIScopes." This reverts commit 342d92c7a0adeabc9ab00f3f0d88d739fe7da4c7. Turns out we're going with a different schema design to represent DW_TAG_imported_modules so we won't need this extra field. llvm-svn: 178215
2013-03-28 03:44:59 +01:00
!9 = metadata !{i32 786468, null, metadata !"int", null, i32 0, i64 32, i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ] [int] [line 0, size 32, align 32, offset 0, enc DW_ATE_signed]
Reapply r160148 (reverted in r163570) fixing spurious breakpoints in modern GDB This reapplies the fix for PR13303 now with more justification. Based on my execution of the GDB 7.5 test suite this results in: expected passes: 16101 -> 20890 (+30%) unexpected failures: 4826 -> 637 (-77%) There are 23 checks that used to pass and now fail. They are all in gdb.reverse. Investigating a few looks like they were accidentally passing due to extra breakpoints being set by this bug. They're generally due to the difference in end location between gcc and clang, the test suite is trying to set breakpoints on the closing '}' that clang doesn't associate with any instructions. llvm-svn: 169304
2012-12-04 22:05:36 +01:00
!10 = metadata !{i32 1, i32 14, metadata !11, null}
Revert "Adding DIImportedModules to DIScopes." This reverts commit 342d92c7a0adeabc9ab00f3f0d88d739fe7da4c7. Turns out we're going with a different schema design to represent DW_TAG_imported_modules so we won't need this extra field. llvm-svn: 178215
2013-03-28 03:44:59 +01:00
!11 = metadata !{i32 786443, metadata !6, metadata !5, i32 1, i32 12, i32 0} ; [ DW_TAG_lexical_block ] [/home/probinson/PR13303.c]
Reference in New Issue Copy Permalink