maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/arm-compiler-rt.c

22 lines
1.3 KiB
C
Raw Normal View History

Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-gnueabi -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABI
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-GNUEABI: "{{.*[/\\]}}libclang_rt.builtins-arm.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-gnueabi -rtlib=compiler-rt -mfloat-abi=hard -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABI-ABI
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-GNUEABI-ABI: "{{.*[/\\]}}libclang_rt.builtins-armhf.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-gnueabihf -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABIHF
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-GNUEABIHF: "{{.*[/\\]}}libclang_rt.builtins-armhf.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-gnueabihf -rtlib=compiler-rt -mfloat-abi=soft -### %s 2>&1 | FileCheck %s -check-prefix ARM-GNUEABIHF-ABI
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-GNUEABIHF-ABI: "{{.*[/\\]}}libclang_rt.builtins-arm.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-windows-itanium -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-WINDOWS
Revert "Driver: use the canonical static library naming" This breaks chromium and its unclear if this is actually a modern convention. This reverts SVN r280169. llvm-svn: 280281
2016-09-01 03:27:07 +08:00
// ARM-WINDOWS: "{{.*[/\\]}}clang_rt.builtins-arm.lib"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-androideabi -rtlib=compiler-rt -### %s 2>&1 | FileCheck %s -check-prefix ARM-ANDROID
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-ANDROID: "{{.*[/\\]}}libclang_rt.builtins-arm-android.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00
// RUN: %clang -target arm-linux-androideabi -rtlib=compiler-rt -mfloat-abi=hard -### %s 2>&1 | FileCheck %s -check-prefix ARM-ANDROIDHF
clang/test/Driver/arm-compiler-rt.c: Relax expressions for dos path. llvm-svn: 248666
2015-09-26 19:17:32 +08:00
// ARM-ANDROIDHF: "{{.*[/\\]}}libclang_rt.builtins-armhf-android.a"
Driver: support ARM/HF on a single toolchain ARM EABI adds target attributes to the object file. Amongst the attributes that are emitted is the VFP argument passing (Hard vs Soft). The linker is responsible for checking these attributes and erroring on mismatches. This causes problems for the compiler-rt builtins when targeting both hard and soft. Because both of these options name the builtins compiler-rt component the same (libclang_rt.builtins-arm.a or libclang_rt.builtins-arm-android). GCC is able to get away with this as it does one target per toolchain. This changes the naming convention for the ARM compiler-rt builtins to differentiate between HF and Soft. Although this means that compiler-rt may be duplicated, it enables supporting both variants from a single toolchain. A similar approach is taken by the Darwin toolchain, naming the library to differentiate between the calling conventions. llvm-svn: 248649
2015-09-26 11:26:44 +08:00