llvm-project/clang/test/CodeGen/debug-info.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

66 lines
1.0 KiB
C
Raw Normal View History

// RUN: %clang_cc1 -triple x86_64-unk-unk -o - -emit-llvm -debug-info-kind=limited %s | FileCheck %s
2008-11-11 14:27:34 +08:00
// PR3023
void convert(void) {
struct { typeof(0) f0; } v0;
}
// PR2784
struct OPAQUE; // CHECK-DAG: DW_TAG_structure_type, name: "OPAQUE"
typedef struct OPAQUE *PTR;
PTR p;
// PR2950
struct s0;
struct s0 { struct s0 *p; } g0;
struct s0 *f0(struct s0 *a0) {
return a0->p;
}
// PR3134
char xpto[];
// PR3427
struct foo {
int a;
void *ptrs[];
};
struct foo bar;
// PR4143
struct foo2 {
enum bar *bar;
};
struct foo2 foo2;
2009-10-23 10:13:20 +08:00
// Radar 7325611
// CHECK-DAG: !DIDerivedType(tag: DW_TAG_typedef, name: "barfoo"
typedef int barfoo;
barfoo foo() {
}
// CHECK-DAG: __uint128_t
__uint128_t foo128 ()
{
__uint128_t int128 = 44;
return int128;
}
// CHECK-DAG: uint64x2_t
typedef unsigned long long uint64_t;
typedef uint64_t uint64x2_t __attribute__((ext_vector_type(2)));
uint64x2_t extvectbar[4];
DebugInfo: Use clang's preferred names for integer types This reverts c7f16ab3e3f27d944db72908c9c1b1b7366f5515 / r109694 - which suggested this was done to improve consistency with the gdb test suite. Possible that at the time GCC did not canonicalize integer types, and so matching types was important for cross-compiler validity, or that it was only a case of over-constrained test cases that printed out/tested the exact names of integer types. In any case neither issue seems to exist today based on my limited testing - both gdb and lldb canonicalize integer types (in a way that happens to match Clang's preferred naming, incidentally) and so never print the original text name produced in the DWARF by GCC or Clang. This canonicalization appears to be in `integer_types_same_name_p` for GDB and in `TypeSystemClang::GetBasicTypeEnumeration` for lldb. (I tested this with one translation unit defining 3 variables - `long`, `long (*)()`, and `int (*)()`, and another translation unit that had main, and a function that took `long (*)()` as a parameter - then compiled them with mismatched compilers (either GCC+Clang, or Clang+(Clang with this patch applied)) and no matter the combination, despite the debug info for one CU naming the type "long int" and the other naming it "long", both debuggers printed out the name as "long" and were able to correctly perform overload resolution and pass the `long int (*)()` variable to the `long (*)()` function parameter) Did find one hiccup, identified by the lldb test suite - that CodeView was relying on these names to map them to builtin types in that format. So added some handling for that in LLVM. (these could be split out into separate patches, but seems small enough to not warrant it - will do that if there ends up needing any reverti/revisiting) Differential Revision: https://reviews.llvm.org/D110455
2021-09-25 07:13:07 +08:00
// CHECK-DAG: !DIBasicType(name: "long"
// CHECK-DAG: !DIBasicType(name: "unsigned long long"
void integral_types(long x, unsigned long long y) {
}