maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/mrtd.c

29 lines
822 B
C
Raw Normal View History

Simplify tests. This reverts bits of r218166 that are no longer necessary now that r218394 made -Wmissing-prototype-for-cc a regular warning. llvm-svn: 218400
2014-09-25 02:25:54 +08:00
// RUN: %clang_cc1 -mrtd -triple i386-unknown-unknown -std=c89 -emit-llvm -o - %s 2>&1 | FileCheck %s
Follow-up to r214408: Warn on other callee-cleanup functions without prototype too. According to lore, we used to verifier-fail on: void __thiscall f(); int main() { f(1); } So that's fixed now. System headers use prototype-less __stdcall functions, so make that a warning that's DefaultError -- then it fires on regular code but is suppressed in system headers. Since it's used in system headers, we have codegen tests for this; massage them slightly so that they still compile. llvm-svn: 218166
2014-09-20 07:07:12 +08:00
Add frontend support for __vectorcall Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
2014-10-25 01:42:17 +08:00
// CHECK: mrtd.c:10:3: warning: function with no prototype cannot use the stdcall calling convention
Implement -mrtd which sets the StdCall calling convention to be the default one. llvm-svn: 126756
2011-03-02 01:40:53 +08:00
void baz(int arg);
Fix testcases to not rely upon target-* attributes. llvm-svn: 176135
2013-02-27 07:08:48 +08:00
// CHECK: define x86_stdcallcc void @foo(i32 %arg) [[NUW:#[0-9]+]]
Implement -mrtd which sets the StdCall calling convention to be the default one. llvm-svn: 126756
2011-03-02 01:40:53 +08:00
void foo(int arg) {
ANSI C requires that a call to an unprototyped function type succeed if the definition has a non-variadic prototype with compatible parameters. Therefore, the default rule for such calls must be to use a non-variadic convention. Achieve this by casting the callee to the function type with which it is required to be compatible, unless the target specifically opts out and insists that unprototyped calls should use the variadic rules. The only case of that I'm aware of is the x86-64 convention, which passes arguments the same way in both cases but also sets a small amount of extra information; here we seek to maintain compatibility with GCC, which does set this when calling an unprototyped function. Addresses PR10810 and PR10713. llvm-svn: 140241
2011-09-21 16:08:30 +08:00
// CHECK: call x86_stdcallcc i32 bitcast (i32 (...)* @bar to i32 (i32)*)(
Implement -mrtd which sets the StdCall calling convention to be the default one. llvm-svn: 126756
2011-03-02 01:40:53 +08:00
bar(arg);
Kill off more names to fix this test llvm-svn: 126775
2011-03-02 03:55:40 +08:00
// CHECK: call x86_stdcallcc void @baz(i32
Implement -mrtd which sets the StdCall calling convention to be the default one. llvm-svn: 126756
2011-03-02 01:40:53 +08:00
baz(arg);
}
// CHECK: declare x86_stdcallcc i32 @bar(...)
// CHECK: declare x86_stdcallcc void @baz(i32)
Modify the tests to use attribute group references instead of listing the function attributes. llvm-svn: 175606
2013-02-20 15:22:19 +08:00
Delete CC_Default and use the target default CC everywhere Summary: Makes functions with implicit calling convention compatible with function types with a matching explicit calling convention. This fixes things like calls to qsort(), which has an explicit __cdecl attribute on the comparator in Windows headers. Clang will now infer the calling convention from the declarator. There are two cases when the CC must be adjusted during redeclaration: 1. When defining a non-inline static method. 2. When redeclaring a function with an implicit or mismatched convention. Fixes PR13457, and allows clang to compile CommandLine.cpp for the Microsoft C++ ABI. Excellent test cases provided by Alexander Zinenko! Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1231 llvm-svn: 189412
2013-08-28 07:08:25 +08:00
void qux(int arg, ...) { }
// CHECK: define void @qux(i32 %arg, ...)
void quux(int a1, int a2, int a3) {
qux(a1, a2, a3);
}
// CHECK-LABEL: define x86_stdcallcc void @quux
[opaque pointer types] Explicit non-pointer type for call expressions (migration for recent LLVM change to textual IR for calls) llvm-svn: 235147
2015-04-17 07:25:00 +08:00
// CHECK: call void (i32, ...) @qux
Delete CC_Default and use the target default CC everywhere Summary: Makes functions with implicit calling convention compatible with function types with a matching explicit calling convention. This fixes things like calls to qsort(), which has an explicit __cdecl attribute on the comparator in Windows headers. Clang will now infer the calling convention from the declarator. There are two cases when the CC must be adjusted during redeclaration: 1. When defining a non-inline static method. 2. When redeclaring a function with an implicit or mismatched convention. Fixes PR13457, and allows clang to compile CommandLine.cpp for the Microsoft C++ ABI. Excellent test cases provided by Alexander Zinenko! Reviewers: rsmith Differential Revision: http://llvm-reviews.chandlerc.com/D1231 llvm-svn: 189412
2013-08-28 07:08:25 +08:00
Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 llvm-svn: 290398
2016-12-23 09:24:49 +08:00
// CHECK: attributes [[NUW]] = { noinline nounwind{{.*}} }