2015-10-08 12:24:12 +08:00
|
|
|
// RUN: %clang_cc1 -w -debug-info-kind=line-tables-only -std=c++11 -fexceptions -fcxx-exceptions -S -emit-llvm %s -o - | FileCheck %s
|
|
|
|
|
// RUN: %clang_cc1 -w -debug-info-kind=line-tables-only -std=c++11 -fexceptions -fcxx-exceptions -S -emit-llvm %s -o - -triple i686-linux-gnu | FileCheck %s
|
2015-01-14 15:38:27 +08:00
|
|
|
|
|
|
|
|
// XFAIL: win32
|
2014-12-09 05:48:57 +08:00
|
|
|
|
2014-12-10 04:52:24 +08:00
|
|
|
int &src();
|
2014-12-10 05:10:43 +08:00
|
|
|
int *sink();
|
2014-12-10 08:47:33 +08:00
|
|
|
extern "C" __complex float complex_src();
|
|
|
|
|
extern "C" __complex float *complex_sink();
|
2014-12-09 05:48:57 +08:00
|
|
|
|
2014-12-10 05:10:43 +08:00
|
|
|
// CHECK-LABEL: define
|
2014-12-09 05:48:57 +08:00
|
|
|
void f1() {
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
*sink()
|
2014-12-09 08:32:22 +08:00
|
|
|
// CHECK: store {{.*}}, !dbg [[DBG_F1:!.*]]
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
#line 100
|
|
|
|
|
= //
|
|
|
|
|
src();
|
2014-12-09 05:48:57 +08:00
|
|
|
}
|
|
|
|
|
|
2014-12-09 08:32:22 +08:00
|
|
|
struct foo {
|
|
|
|
|
int i;
|
|
|
|
|
int &j;
|
2014-12-10 04:52:24 +08:00
|
|
|
__complex float k;
|
2014-12-09 08:32:22 +08:00
|
|
|
foo();
|
|
|
|
|
};
|
|
|
|
|
|
2014-12-10 05:10:43 +08:00
|
|
|
// CHECK-LABEL: define
|
2014-12-09 08:32:22 +08:00
|
|
|
foo::foo()
|
2014-12-10 05:10:43 +08:00
|
|
|
:
|
2014-12-09 08:32:22 +08:00
|
|
|
#line 200
|
2014-12-10 05:10:43 +08:00
|
|
|
i // CHECK: store i32 {{.*}} !dbg [[DBG_FOO_VALUE:!.*]]
|
|
|
|
|
(src()),
|
|
|
|
|
j // CHECK: store i32* {{.*}} !dbg [[DBG_FOO_REF:!.*]]
|
|
|
|
|
(src()),
|
|
|
|
|
k // CHECK: store float {{.*}} !dbg [[DBG_FOO_COMPLEX:!.*]]
|
|
|
|
|
(complex_src()) {
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-10 08:47:33 +08:00
|
|
|
// CHECK-LABEL: define {{.*}}f2{{.*}}
|
2014-12-10 05:10:43 +08:00
|
|
|
void f2() {
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
// CHECK: store float {{.*}} !dbg [[DBG_F2:!.*]]
|
|
|
|
|
*complex_sink()
|
2014-12-10 05:10:43 +08:00
|
|
|
#line 300
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
= //
|
|
|
|
|
complex_src();
|
2014-12-09 08:32:22 +08:00
|
|
|
}
|
|
|
|
|
|
2014-12-10 05:32:00 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f3() {
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
// CHECK: store float {{.*}} !dbg [[DBG_F3:!.*]]
|
|
|
|
|
*complex_sink()
|
2014-12-10 05:32:00 +08:00
|
|
|
#line 400
|
DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
2015-01-25 09:19:10 +08:00
|
|
|
+= //
|
|
|
|
|
complex_src();
|
2014-12-10 05:32:00 +08:00
|
|
|
}
|
|
|
|
|
|
2014-12-10 06:04:13 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f4() {
|
|
|
|
|
#line 500
|
|
|
|
|
auto x // CHECK: store {{.*}} !dbg [[DBG_F4:!.*]]
|
|
|
|
|
= src();
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-10 06:15:02 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f5() {
|
|
|
|
|
#line 600
|
|
|
|
|
auto x // CHECK: store float {{.*}} !dbg [[DBG_F5:!.*]]
|
|
|
|
|
= complex_src();
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-10 07:33:26 +08:00
|
|
|
struct agg { int i; };
|
|
|
|
|
agg agg_src();
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f6() {
|
|
|
|
|
agg x;
|
2015-01-25 09:25:37 +08:00
|
|
|
// CHECK: call void @llvm.memcpy{{.*}} !dbg [[DBG_F6:!.*]]
|
|
|
|
|
x
|
2014-12-10 07:33:26 +08:00
|
|
|
#line 700
|
2015-01-25 09:25:37 +08:00
|
|
|
= //
|
|
|
|
|
agg_src();
|
2014-12-10 07:33:26 +08:00
|
|
|
}
|
|
|
|
|
|
2014-12-10 09:03:48 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f7() {
|
|
|
|
|
int *src1();
|
|
|
|
|
int src2();
|
|
|
|
|
#line 800
|
|
|
|
|
int x = ( // CHECK: load {{.*}} !dbg [[DBG_F7:!.*]]
|
|
|
|
|
src1())[src2()];
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-10 09:16:09 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f8() {
|
|
|
|
|
int src1[1];
|
|
|
|
|
int src2();
|
|
|
|
|
#line 900
|
|
|
|
|
int x = ( // CHECK: load {{.*}} !dbg [[DBG_F8:!.*]]
|
|
|
|
|
src1)[src2()];
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-10 09:34:25 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f9(int i) {
|
|
|
|
|
int src1[1][i];
|
|
|
|
|
int src2();
|
|
|
|
|
#line 1000
|
|
|
|
|
auto x = ( // CHECK: getelementptr {{.*}} !dbg [[DBG_F9:!.*]]
|
|
|
|
|
src1)[src2()];
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-15 02:48:18 +08:00
|
|
|
inline void *operator new(decltype(sizeof(1)), void *p) noexcept { return p; }
|
2014-12-11 03:04:09 +08:00
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f10() {
|
|
|
|
|
void *void_src();
|
2015-02-14 09:52:20 +08:00
|
|
|
(
|
2014-12-15 02:48:18 +08:00
|
|
|
// CHECK: store {{.*}} !dbg [[DBG_F10_STORE:!.*]]
|
2014-12-11 03:04:09 +08:00
|
|
|
#line 1100
|
|
|
|
|
new (void_src()) int(src()));
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-14 15:10:46 +08:00
|
|
|
// noexcept just to simplify the codegen a bit
|
|
|
|
|
void fn() noexcept(true);
|
|
|
|
|
|
|
|
|
|
struct bar {
|
|
|
|
|
bar();
|
|
|
|
|
// noexcept(false) to convolute the global dtor
|
|
|
|
|
~bar() noexcept(false);
|
|
|
|
|
};
|
|
|
|
|
// global ctor cleanup
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
// CHECK: invoke{{ }}
|
|
|
|
|
// CHECK: invoke{{ }}
|
|
|
|
|
// CHECK: to label {{.*}}, !dbg [[DBG_GLBL_CTOR_B:!.*]]
|
2015-01-14 15:38:27 +08:00
|
|
|
|
|
|
|
|
// terminate caller
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
|
2015-01-14 15:10:46 +08:00
|
|
|
// global dtor cleanup
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
// CHECK: invoke{{ }}
|
|
|
|
|
// CHECK: invoke{{ }}
|
|
|
|
|
// CHECK: to label {{.*}}, !dbg [[DBG_GLBL_DTOR_B:!.*]]
|
2015-01-17 06:55:09 +08:00
|
|
|
#line 1200
|
2015-01-14 15:10:46 +08:00
|
|
|
bar b[1] = { //
|
|
|
|
|
(fn(), //
|
|
|
|
|
bar())};
|
|
|
|
|
|
2015-01-14 15:38:27 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
__complex double f11() {
|
|
|
|
|
__complex double f;
|
|
|
|
|
// CHECK: store {{.*}} !dbg [[DBG_F11:!.*]]
|
2015-01-17 06:55:09 +08:00
|
|
|
#line 1300
|
2015-01-14 15:38:27 +08:00
|
|
|
return f;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f12() {
|
|
|
|
|
int f12_1();
|
|
|
|
|
void f12_2(int = f12_1());
|
2015-06-30 01:29:50 +08:00
|
|
|
// CHECK: call {{.*}}{{(signext )?}}i32 {{.*}} !dbg [[DBG_F12:!.*]]
|
2015-01-17 06:55:09 +08:00
|
|
|
#line 1400
|
2015-01-14 15:38:27 +08:00
|
|
|
f12_2();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f13() {
|
|
|
|
|
// CHECK: call {{.*}} !dbg [[DBG_F13:!.*]]
|
|
|
|
|
#define F13_IMPL 1, src()
|
|
|
|
|
1,
|
2015-01-17 06:55:09 +08:00
|
|
|
#line 1500
|
2015-01-14 15:38:27 +08:00
|
|
|
F13_IMPL;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-18 09:48:19 +08:00
|
|
|
struct f14_impl {
|
|
|
|
|
f14_impl(int);
|
2015-01-17 06:55:09 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
2015-01-18 08:37:04 +08:00
|
|
|
struct f14_use {
|
2015-01-18 09:48:19 +08:00
|
|
|
// CHECK: call {{.*}}f14_impl{{.*}}, !dbg [[DBG_F14_CTOR_CALL:![0-9]*]]
|
2015-01-17 06:55:09 +08:00
|
|
|
#line 1600
|
2015-01-18 09:48:19 +08:00
|
|
|
f14_impl v{//
|
|
|
|
|
1};
|
2015-01-18 08:37:04 +08:00
|
|
|
f14_use();
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
f14_use::f14_use() = default;
|
2015-01-17 06:55:09 +08:00
|
|
|
|
2015-01-18 09:57:54 +08:00
|
|
|
// CHECK-LABEL: define
|
2015-01-17 06:55:09 +08:00
|
|
|
// CHECK-LABEL: define
|
2015-01-18 09:48:19 +08:00
|
|
|
void func(foo);
|
|
|
|
|
void f15(foo *f) {
|
|
|
|
|
func(
|
|
|
|
|
// CHECK: getelementptr {{.*}}, !dbg [[DBG_F15:![0-9]*]]
|
|
|
|
|
#line 1700
|
|
|
|
|
f[3]);
|
|
|
|
|
}
|
2015-01-17 06:55:09 +08:00
|
|
|
|
2015-01-18 09:57:54 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f16(__complex float f) {
|
|
|
|
|
__complex float g = //
|
|
|
|
|
// CHECK: add {{.*}}, !dbg [[DBG_F16:![0-9]*]]
|
|
|
|
|
#line 1800
|
|
|
|
|
f + 1;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-25 07:35:17 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f17(int *x) {
|
|
|
|
|
1,
|
|
|
|
|
// CHECK: getelementptr {{.*}}, !dbg [[DBG_F17:![0-9]*]]
|
|
|
|
|
#line 1900
|
|
|
|
|
x[1];
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-29 03:50:09 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f18(int a, int b) {
|
|
|
|
|
// CHECK: icmp {{.*}}, !dbg [[DBG_F18_1:![0-9]*]]
|
|
|
|
|
// CHECK: br {{.*}}, !dbg [[DBG_F18_2:![0-9]*]]
|
|
|
|
|
#line 2000
|
|
|
|
|
if (a //
|
|
|
|
|
&& //
|
|
|
|
|
b)
|
|
|
|
|
;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f19(int a, int b) {
|
|
|
|
|
// CHECK: icmp {{.*}}, !dbg [[DBG_F19_1:![0-9]*]]
|
|
|
|
|
// CHECK: br {{.*}}, !dbg [[DBG_F19_2:![0-9]*]]
|
|
|
|
|
#line 2100
|
|
|
|
|
if (a //
|
|
|
|
|
|| //
|
|
|
|
|
b)
|
|
|
|
|
;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f20(int a, int b, int c) {
|
|
|
|
|
// CHECK: icmp {{.*}}, !dbg [[DBG_F20_1:![0-9]*]]
|
|
|
|
|
// FIXME: Conditional operator's exprloc should be the '?' not the start of the
|
|
|
|
|
// expression, then this would go in the right place. (but adding getExprLoc to
|
|
|
|
|
// the ConditionalOperator breaks the ARC migration tool - need to investigate
|
|
|
|
|
// further).
|
|
|
|
|
// CHECK: br {{.*}}, !dbg [[DBG_F20_1]]
|
|
|
|
|
#line 2200
|
|
|
|
|
if (a //
|
|
|
|
|
? //
|
|
|
|
|
b : c)
|
|
|
|
|
;
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-04 06:37:17 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
int f21_a(int = 0);
|
|
|
|
|
void f21_b(int = f21_a());
|
|
|
|
|
void f21() {
|
|
|
|
|
// CHECK: call {{.*}}f21_b{{.*}}, !dbg [[DBG_F21:![0-9]*]]
|
|
|
|
|
#line 2300
|
|
|
|
|
f21_b();
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-05 03:47:54 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
struct f22_dtor {
|
|
|
|
|
~f22_dtor();
|
|
|
|
|
};
|
|
|
|
|
void f22() {
|
|
|
|
|
{
|
|
|
|
|
f22_dtor f;
|
|
|
|
|
src();
|
2015-02-05 09:02:34 +08:00
|
|
|
// CHECK: invoke {{.*}}src
|
2015-02-05 03:47:54 +08:00
|
|
|
// CHECK: call {{.*}}, !dbg [[DBG_F22:![0-9]*]]
|
|
|
|
|
// CHECK: call {{.*}}, !dbg [[DBG_F22]]
|
|
|
|
|
#line 2400
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-10 02:47:14 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
struct f23_struct {
|
|
|
|
|
};
|
|
|
|
|
f23_struct f23_a();
|
|
|
|
|
void f23_b(f23_struct = f23_a());
|
|
|
|
|
void f23() {
|
|
|
|
|
// CHECK: call {{.*}}f23_a{{.*}}, !dbg [[DBG_F23:![0-9]*]]
|
|
|
|
|
#line 2500
|
|
|
|
|
f23_b();
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-10 02:55:57 +08:00
|
|
|
// CHECK-LABEL: define
|
|
|
|
|
void f24_a(__complex float = complex_src());
|
|
|
|
|
void f24() {
|
|
|
|
|
// CHECK: call {{.*}}complex_src{{.*}}, !dbg [[DBG_F24:![0-9]*]]
|
|
|
|
|
#line 2600
|
|
|
|
|
f24_a();
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-30 00:40:08 +08:00
|
|
|
// CHECK: [[DBG_F1]] = !DILocation(line: 100,
|
|
|
|
|
// CHECK: [[DBG_FOO_VALUE]] = !DILocation(line: 200,
|
|
|
|
|
// CHECK: [[DBG_FOO_REF]] = !DILocation(line: 202,
|
|
|
|
|
// CHECK: [[DBG_FOO_COMPLEX]] = !DILocation(line: 204,
|
|
|
|
|
// CHECK: [[DBG_F2]] = !DILocation(line: 300,
|
|
|
|
|
// CHECK: [[DBG_F3]] = !DILocation(line: 400,
|
|
|
|
|
// CHECK: [[DBG_F4]] = !DILocation(line: 500,
|
|
|
|
|
// CHECK: [[DBG_F5]] = !DILocation(line: 600,
|
|
|
|
|
// CHECK: [[DBG_F6]] = !DILocation(line: 700,
|
|
|
|
|
// CHECK: [[DBG_F7]] = !DILocation(line: 800,
|
|
|
|
|
// CHECK: [[DBG_F8]] = !DILocation(line: 900,
|
|
|
|
|
// CHECK: [[DBG_F9]] = !DILocation(line: 1000,
|
|
|
|
|
// CHECK: [[DBG_F10_STORE]] = !DILocation(line: 1100,
|
|
|
|
|
// CHECK: [[DBG_GLBL_CTOR_B]] = !DILocation(line: 1200,
|
|
|
|
|
// CHECK: [[DBG_GLBL_DTOR_B]] = !DILocation(line: 1200,
|
|
|
|
|
// CHECK: [[DBG_F11]] = !DILocation(line: 1300,
|
|
|
|
|
// CHECK: [[DBG_F12]] = !DILocation(line: 1400,
|
|
|
|
|
// CHECK: [[DBG_F13]] = !DILocation(line: 1500,
|
|
|
|
|
// CHECK: [[DBG_F14_CTOR_CALL]] = !DILocation(line: 1600,
|
|
|
|
|
// CHECK: [[DBG_F15]] = !DILocation(line: 1700,
|
|
|
|
|
// CHECK: [[DBG_F16]] = !DILocation(line: 1800,
|
|
|
|
|
// CHECK: [[DBG_F17]] = !DILocation(line: 1900,
|
|
|
|
|
// CHECK: [[DBG_F18_1]] = !DILocation(line: 2000,
|
|
|
|
|
// CHECK: [[DBG_F18_2]] = !DILocation(line: 2001,
|
|
|
|
|
// CHECK: [[DBG_F19_1]] = !DILocation(line: 2100,
|
|
|
|
|
// CHECK: [[DBG_F19_2]] = !DILocation(line: 2101,
|
|
|
|
|
// CHECK: [[DBG_F20_1]] = !DILocation(line: 2200,
|
|
|
|
|
// CHECK: [[DBG_F23]] = !DILocation(line: 2500,
|
|
|
|
|
// CHECK: [[DBG_F24]] = !DILocation(line: 2600,
|