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/darwin-ld-lto.c

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

33 lines
1.3 KiB
C
Raw Normal View History

[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// REQUIRES: system-darwin
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// Check that ld gets "-lto_library".
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
[clang] Get rid of "%T" expansions The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t. This patch removes %T in clang. Differential Revision: https://reviews.llvm.org/D36437 llvm-svn: 310950
2017-08-16 03:47:06 +08:00
// RUN: mkdir -p %t/bin
// RUN: mkdir -p %t/lib
// RUN: touch %t/lib/libLTO.dylib
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -### %s \
[clang] Get rid of "%T" expansions The %T lit expansion expands to a common directory shared between all the tests in the same directory, which is unexpected and unintuitive, and more importantly, it's been a source of subtle race conditions and flaky tests. In https://reviews.llvm.org/D35396, it was agreed that it would be best to simply ban %T and only keep %t, which is unique to each test. When a test needs a temporary directory, it can just create one using mkdir %t. This patch removes %T in clang. Differential Revision: https://reviews.llvm.org/D36437 llvm-svn: 310950
2017-08-16 03:47:06 +08:00
// RUN: -ccc-install-dir %t/bin -mlinker-version=133 2> %t.log
[test] Pass a fake libLTO.dylib to a driver test which depends on it This makes it possible to run 'check-clang' on Darwin without building libLTO.dylib. See r280142 for more context. llvm-svn: 280150
2016-08-31 04:36:50 +08:00
// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH %s -input-file %t.log
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
//
// LINK_LTOLIB_PATH: {{ld(.exe)?"}}
// LINK_LTOLIB_PATH: "-lto_library"
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// Also pass -lto_library even if the file doesn't exist; if it's needed at
// link time, ld will complain instead.
[DarwinDriver] Reapply: Use -lto_library to specify the path for libLTO.dylib Reapply r248935. Usually, when using LTO with a clang installation newer than the system's one, there's a libLTO.dylib version mismatch and LTO fails. One solution to this is to make ld point to the right libLTO.dylib by changing DYLD_LIBRARY_PATH. However, ld64 supports specifying the complete path to the desired libLTO.dylib through the -lto_library option. This commit adds support for the clang driver to use this option whenever it's capable of finding a libLTO.dylib in clang's installed library directory. This way, we don't need to rely on DYLD_LIBRARY_PATH nor get caught by version mismatches. Differential Revision: http://reviews.llvm.org/D13117 rdar://problem/7363476 llvm-svn: 249143
2015-10-02 23:10:33 +08:00
// RUN: %clang -target x86_64-apple-darwin10 -### %s \
Unconditionally pass `-lto_library` to the linker on Darwin We're only doing it with -flto currently, however it never "hurt" to pass it, and users that are linking without -flto can get in trouble if one of the dependency (a static library for instance) contains bitcode. Differential Revision: https://reviews.llvm.org/D25932 llvm-svn: 285254
2016-10-27 07:23:08 +08:00
// RUN: -ccc-install-dir %S/dummytestdir -mlinker-version=133 2> %t.log
darwin: Unconditionally pass -lto_library, remove -Wliblto warning. https://reviews.llvm.org/D25932 made it so that clang always checks if libLTO.dylib is present on disk, even if -flto is not being used. The motivation for that change was that if a dependency happens to contain bitcode, ld64 will try to load libLTO without -flto explicitly being enabled. However, the change had the undesirable side effect of warning if libLTO.dylib doesn't exist even if it isn't needed. Change things so that -lto_library is always passes, independent of if it exists or not. ld64 only looks at this flag if it uses LTO. If the dylib exists, all is well. If it doesn't, and LTO is not being used, all is well too. If ld64 does end up using LTO and the dylib does not exist, ld64 will print something like ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64 https://reviews.llvm.org/D26984 llvm-svn: 287685
2016-11-23 03:38:07 +08:00
// RUN: FileCheck -check-prefix=LINK_LTOLIB_PATH %s -input-file %t.log
[Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO Summary: After r327851, Driver::GetTemporaryPath will create the file rather than just create a potientially unqine filename. If clang driver pass the file as parameter as -object_path_lto, ld64 will pass it back to libLTO as GeneratedObjectsDirectory, which is going to cause a LLVM ERROR if it is not a directory. Now during thinLTO, pass a temp directory path to linker instread. rdar://problem/47194182 Reviewers: arphaman, dexonsmith Reviewed By: arphaman Subscribers: mehdi_amini, inglorion, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D56608 llvm-svn: 350970
2019-01-12 05:16:04 +08:00
// Check that -object_lto_path is passed correctly to ld64
// RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
// RUN: FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
Fix the tests from r350970 Relax the tests from r350970 to allow non-standard path for ld. llvm-svn: 352537
2019-01-30 04:13:02 +08:00
// FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
Fix darwin-ld-lto test for some speical path Fix the test by not assuming the prefix path of the temp directory can be matched by a regex. rdar://problem/56259195 llvm-svn: 375027
2019-10-17 02:12:41 +08:00
// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
// FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
[Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO Summary: After r327851, Driver::GetTemporaryPath will create the file rather than just create a potientially unqine filename. If clang driver pass the file as parameter as -object_path_lto, ld64 will pass it back to libLTO as GeneratedObjectsDirectory, which is going to cause a LLVM ERROR if it is not a directory. Now during thinLTO, pass a temp directory path to linker instread. rdar://problem/47194182 Reviewers: arphaman, dexonsmith Reviewed By: arphaman Subscribers: mehdi_amini, inglorion, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D56608 llvm-svn: 350970
2019-01-12 05:16:04 +08:00
// RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
// RUN: FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
Fix the tests from r350970 Relax the tests from r350970 to allow non-standard path for ld. llvm-svn: 352537
2019-01-30 04:13:02 +08:00
// THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
Fix darwin-ld-lto test for some speical path Fix the test by not assuming the prefix path of the temp directory can be matched by a regex. rdar://problem/56259195 llvm-svn: 375027
2019-10-17 02:12:41 +08:00
// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
// THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}