blob: 04d9493ae6b0867f3a4903acb453626f0d3b257b [file] [log] [blame]
Tim Northoverc264e162013-01-31 12:13:10 +00001// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -emit-llvm -w -o - %s | FileCheck %s
2
3// Check differences between the generic Itanium ABI, the AArch32 version and
4// the AArch64 version.
5
6////////////////////////////////////////////////////////////////////////////////
7
8// The ABI says that the key function is the "textually first, non-inline,
9// non-pure, virtual member function". The generic version decides this after
10// the completion of the class definition; the AArch32 version decides this at
11// the end of the translation unit.
12
13// We construct a class which needs a VTable here under generic ABI, but not
14// AArch32.
15
16// (see next section for explanation of guard)
17// CHECK: @_ZGVZ15guard_variablesiE4mine = internal global i64 0
18
19// CHECK: @_ZTV16CheckKeyFunction =
20struct CheckKeyFunction {
21 virtual void foo();
22};
23
24// This is not inline when CheckKeyFunction is completed, so
25// CheckKeyFunction::foo is the key function. VTables should be emitted.
26inline void CheckKeyFunction::foo() {
27}
28
29////////////////////////////////////////////////////////////////////////////////
30
31// Guard variables only specify and use the low bit to determine status, rather
32// than the low byte as in the generic Itanium ABI. However, unlike 32-bit ARM,
33// they *are* 64-bits wide so check that in case confusion has occurred.
34
35class Guarded {
36public:
37 Guarded(int i);
38 ~Guarded();
39};
40
41void guard_variables(int a) {
42 static Guarded mine(a);
43// CHECK: [[GUARDBIT:%[0-9]+]] = and i64 {{%[0-9]+}}, 1
44// CHECK: icmp eq i64 [[GUARDBIT]], 0
45
46 // As guards are 64-bit, these helpers should take 64-bit pointers.
47// CHECK: call i32 @__cxa_guard_acquire(i64*
48// CHECK: call void @__cxa_guard_release(i64*
49}
50
51////////////////////////////////////////////////////////////////////////////////
52
53// Member function pointers use the adj field to distinguish between virtual and
54// nonvirtual members. As a result the adjustment is shifted (if ptr was used, a
55// mask would be expected instead).
56
57class C {
58 int a();
59 virtual int b();
60};
61
62
63int member_pointer(C &c, int (C::*func)()) {
64// CHECK: ashr i64 %[[MEMPTRADJ:[0-9a-z.]+]], 1
65// CHECK: %[[ISVIRTUAL:[0-9]+]] = and i64 %[[MEMPTRADJ]], 1
66// CHECK: icmp ne i64 %[[ISVIRTUAL]], 0
67 return (c.*func)();
68}
69
70////////////////////////////////////////////////////////////////////////////////
71
72// AArch64 PCS says that va_list type is based on "struct __va_list ..." in the
73// std namespace, which means it should mangle as "St9__va_list".
74
75// CHECK: @_Z7va_funcSt9__va_list
76void va_func(__builtin_va_list l) {
77}
78
79////////////////////////////////////////////////////////////////////////////////
80
81// AArch64 constructors (like generic Itanium, but unlike AArch32) do not return
82// "this".
83
84void test_constructor() {
85 Guarded g(42);
86// CHECK: call void @_ZN7GuardedC1Ei
87}
88
89////////////////////////////////////////////////////////////////////////////////
90
91// In principle the AArch32 ABI allows this to be accomplished via a call to
92// __aeabi_atexit instead of __cxa_atexit. Clang doesn't make use of this at the
93// moment, but it's definitely not allowed for AArch64.
94
95// CHECK: call i32 @__cxa_atexit
96Guarded g(42);