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/mangle-windows.c

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

84 lines
3.3 KiB
C
Raw Normal View History

Remove the -cxx-abi command-line flag. This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples, Itanium otherwise. It's no longer possible to do weird combinations. To be able to run a test with a specific ABI without constraining it to a specific triple, new substitutions are added to lit: %itanium_abi_triple and %ms_abi_triple can be used to get the current target triple adjusted to the desired ABI. For example, if the test suite is running with the i686-pc-win32 target, %itanium_abi_triple will expand to i686-pc-mingw32. Differential Revision: http://llvm-reviews.chandlerc.com/D2545 llvm-svn: 199250
2014-01-15 03:35:09 +08:00
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i386-pc-win32 | FileCheck %s
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i386-mingw32 | FileCheck %s
Fix data layout mismatch between LLVM and Clang for i686-pc-windows-msvc-elf Do the same thing as win64. If we're not using COFF, use the ELF manglings. Maybe if we are targetting *-windows-msvc-macho, we should use darwin manglings, but I don't need to stir that pot today. llvm-svn: 233819
2015-04-02 00:45:06 +08:00
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i386-pc-windows-msvc-elf | FileCheck %s --check-prefix=ELF32
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-pc-win32 | FileCheck %s --check-prefix=X64
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-mingw32 | FileCheck %s --check-prefix=X64
Fix data layout mismatch between LLVM and Clang for i686-pc-windows-msvc-elf Do the same thing as win64. If we're not using COFF, use the ELF manglings. Maybe if we are targetting *-windows-msvc-macho, we should use darwin manglings, but I don't need to stir that pot today. llvm-svn: 233819
2015-04-02 00:45:06 +08:00
// RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-pc-windows-msvc-elf | FileCheck %s --check-prefix=ELF64
// CHECK: target datalayout = "e-m:x-{{.*}}"
// X64: target datalayout = "e-m:w-{{.*}}"
// ELF32: target datalayout = "e-m:e-{{.*}}"
// ELF64: target datalayout = "e-m:e-{{.*}}"
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __stdcall f1(void) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_stdcallcc void @"\01_f1@0"
// X64: define dso_local void @f1(
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// ELF32: define x86_stdcallcc void @"\01_f1@0"
// ELF64: define void @f1(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f2(void) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f2@0"
// X64: define dso_local void @f2(
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// ELF32: define x86_fastcallcc void @"\01@f2@0"
// ELF64: define void @f2(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __stdcall f3() {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_stdcallcc void @"\01_f3@0"
// X64: define dso_local void @f3(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f4(char a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f4@4"
// X64: define dso_local void @f4(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f5(short a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f5@4"
// X64: define dso_local void @f5(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f6(int a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f6@4"
// X64: define dso_local void @f6(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f7(long a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f7@4"
// X64: define dso_local void @f7(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f8(long long a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f8@8"
// X64: define dso_local void @f8(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void __fastcall f9(long long a, char b, char c, short d) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_fastcallcc void @"\01@f9@20"(i64 %a, i8 signext %b, i8 signext %c, i16 signext %d)
// X64: define dso_local void @f9(
On 32 bit windows, mangle stdcall and fastcall decls in clang. This removes the dependency on the llvm mangler doing it for us. In isolation, the benefit is that the testing of what mangling is applied is all in one place: (C, C++) X (Itanium, Microsoft) are all handled by clang. This also gives me hope that in the future the llvm mangler (and llvm-ar) will not depend on TargetMachine. llvm-svn: 192762
2013-10-16 09:40:34 +08:00
void f12(void) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local void @f12(
// X64: define dso_local void @f12(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v1(void) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v1@@0"(
// X64: define dso_local x86_vectorcallcc void @"\01v1@@0"(
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// ELF32: define x86_vectorcallcc void @"\01v1@@0"(
// ELF64: define x86_vectorcallcc void @"\01v1@@0"(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v2(char a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v2@@4"(
// X64: define dso_local x86_vectorcallcc void @"\01v2@@8"(
Revert "[CodeGenModule] Assume dso_local for -fpic -fno-semantic-interposition" This reverts commit 789a46f2d742e11edaade28cb59a0f4d2a1d770e. Accidentally committed.
2020-02-04 02:09:39 +08:00
// ELF32: define x86_vectorcallcc void @"\01v2@@4"(
// ELF64: define x86_vectorcallcc void @"\01v2@@8"(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v3(short a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v3@@4"(
// X64: define dso_local x86_vectorcallcc void @"\01v3@@8"(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v4(int a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v4@@4"(
// X64: define dso_local x86_vectorcallcc void @"\01v4@@8"(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v5(long long a) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v5@@8"(
// X64: define dso_local x86_vectorcallcc void @"\01v5@@8"(
Implement IRGen for the x86 vectorcall convention The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
2014-11-01 06:00:51 +08:00
void __vectorcall v6(char a, char b) {}
Bring r325915 back. The tests that failed on a windows host have been fixed. Original message: Start setting dso_local for COFF. With this there are still some GVs where we don't set dso_local because setGVProperties is never called. I intend to fix that in followup commits. This is just the bare minimum to teach shouldAssumeDSOLocal what it should do for COFF. llvm-svn: 325940
2018-02-24 03:30:48 +08:00
// CHECK: define dso_local x86_vectorcallcc void @"\01v6@@8"(
// X64: define dso_local x86_vectorcallcc void @"\01v6@@16"(