maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/runtimecc.cpp

54 lines
1.8 KiB
C++
Raw Normal View History

Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
// RUN: %clang_cc1 %s -triple=armv7-apple-darwin10 -emit-llvm -o - -fexceptions -fcxx-exceptions | FileCheck %s
// Check that we annotate all compiler-synthesized runtime calls and
// functions with the actual ABI-determined CC. This usually doesn't
// matter as long as we're internally consistent (and the LLVM-default
// CC is consistent with the real one), but it's possible for user
// translation units to define these runtime functions (or, equivalently,
// for us to get LTO'ed with such a translation unit), and then the
// mismatch will kill us.
//
// rdar://12818655
// CHECK: [[A:%.*]] = type { double }
namespace test0 {
struct A {
double d;
A();
~A();
};
A global;
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK-LABEL: define internal void @__cxx_global_var_init()
[CodeGenCXX] Treat 'this' as noalias in constructors This is currently a clang extension and a resolution of the defect report in the C++ Standard. Differential Revision: https://reviews.llvm.org/D46441 llvm-svn: 344150
2018-10-11 00:14:51 +08:00
// CHECK: call [[A]]* @_ZN5test01AC1Ev([[A]]* noalias @_ZN5test06globalE)
Introduce CGCXXABI::canCallMismatchedFunctionType llvm-svn: 269089
2016-05-11 01:44:55 +08:00
// CHECK-NEXT: call i32 @__cxa_atexit(void (i8*)* bitcast ([[A]]* ([[A]]*)* @_ZN5test01AD1Ev to void (i8*)*), i8* bitcast ([[A]]* @_ZN5test06globalE to i8*), i8* @__dso_handle) [[NOUNWIND:#[0-9]+]]
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
// CHECK-NEXT: ret void
}
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK: declare i32 @__cxa_atexit(void (i8*)*, i8*, i8*) [[NOUNWIND]]
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
namespace test1 {
void test() {
throw 0;
}
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK-LABEL: define void @_ZN5test14testEv()
// CHECK: [[T0:%.*]] = call i8* @__cxa_allocate_exception(i32 4) [[NOUNWIND]]
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
// CHECK-NEXT: [[T1:%.*]] = bitcast i8* [[T0]] to i32*
// CHECK-NEXT: store i32 0, i32* [[T1]]
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK-NEXT: call void @__cxa_throw(i8* [[T0]], i8* bitcast (i8** @_ZTIi to i8*), i8* null) [[NORETURN:#[0-9]+]]
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
// CHECK-NEXT: unreachable
}
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK: declare i8* @__cxa_allocate_exception(i32)
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK: declare void @__cxa_throw(i8*, i8*, i8*)
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
Have the driver and the target code agree on what the default ABI is for each machine. Fix up darwin tests that were testing for aapcs on armv7-ios when the actual ABI is apcs. Should be no user visible change without -cc1. llvm-svn: 223429
2014-12-05 09:06:59 +08:00
// CHECK-LABEL: define internal void @_GLOBAL__sub_I_runtimecc.cpp()
// CHECK: call void @__cxx_global_var_init()
Use the actual ABI-determined C calling convention for runtime calls and declarations. LLVM has a default CC determined by the target triple. This is not always the actual default CC for the ABI we've been asked to target, and so we sometimes find ourselves annotating all user functions with an explicit calling convention. Since these calling conventions usually agree for the simple set of argument types passed to most runtime functions, using the LLVM-default CC in principle has no effect. However, the LLVM optimizer goes into histrionics if it sees this kind of formal CC mismatch, since it has no concept of CC compatibility. Therefore, if this module happens to define the "runtime" function, or got LTO'ed with such a definition, we can miscompile; so it's quite important to get this right. Defining runtime functions locally is quite common in embedded applications. llvm-svn: 176286
2013-03-01 03:01:20 +08:00
// CHECK: attributes [[NOUNWIND]] = { nounwind }
// CHECK: attributes [[NORETURN]] = { noreturn }