summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
* [Driver][Darwin] Disable default stack protector levels in freestanding mode.Bruno Cardoso Lopes2016-12-081-1/+8
| | | | | | | | | Currently -fstack-protector is on by default when using -ffreestanding. Change the default behavior to have it off when using -ffreestanding. rdar://problem/14089363 llvm-svn: 289005
* Refactor how the MSVC toolchain searches for a compatibility version.David L. Jones2016-12-075-84/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MSVC toolchain and Clang driver combination currently uses a fairly complex sequence of steps to determine the MS compatibility version to pass to cc1. There is some oddness in this sequence currently, with some code which inspects flags in the toolchain, and some code which inspects the triple and local environment in the driver code. This change is an attempt to consolidate most of this logic so that Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the split, so any suggestions are welcome. There are a few things you might want to watch for for specifically: - On all platforms, if MSVC compatibility flags are provided (and valid), use those. - The fallback sequence should be the same as before, but is now consolidated into MSVCToolChain::getMSVCVersion: - Otherwise, try to use the Triple. - Otherwise, on Windows, check the executable. - Otherwise, on Windows or with --fms-extensions, default to 18. - Otherwise, we can't determine the version. - MSVCToolChain::ComputeEffectiveTriple no longer calls the base ToolChain::ComputeEffectiveClangTriple. The only thing it would change for Windows the architecture, which we don't care about for the compatibility version. - I'm not sure whether this is philosophically correct (but it should be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not). - Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look like the effective triple was always being used previously anyhow. Reviewers: hans, compnerd, llvm-commits, rnk Subscribers: amccarth Differential Revision: https://reviews.llvm.org/D27477 llvm-svn: 288998
* Driver: Remove support for -fobjc-gc*Duncan P. N. Exon Smith2016-12-071-19/+0
| | | | | | | | | | | | As a first step toward removing Objective-C garbage collection from Clang, remove support from the driver. I'm hoping this will flush out any expected bots/configurations/whatever that might rely on it. I've left the options behind temporarily in -cc1 to keep tests passing. I'll kill them off entirely in a follow up when I've had a chance to update/delete the rest of Clang. llvm-svn: 288872
* If clang was configured for a DEFAULT_SYSROOT and no --sysroot argumentJoerg Sonnenberger2016-12-061-0/+5
| | | | | | is seen, record one with the implicit default. llvm-svn: 288822
* Allow clang to write compilation database records.Joerg Sonnenberger2016-12-062-1/+67
| | | | | | | | | | | | | | | | | | | | When integrating compilation database output into existing build systems, two approaches dominate so far. Ad-hoc implementation of the JSON output rules or using compiler wrappers. This patch adds a new option "-MJ foo.json" which gives a slightly cleaned up compilation record. The output is a fragment, i.e. you still need to add the array markers, but it allows multiple files to be easy merged. This way the only change in a build system is adding the option with potentially a per-target output file and merging the files with something like (echo '['; cat *.o.json; echo ']' > compilation_database.json or some additional filtering to remove the trailing comma for strict JSON compliance. Differential Revision: https://reviews.llvm.org/D27140 llvm-svn: 288821
* [clang] Fix D26214: Move error handling out of MC and to the callers.Mandeep Singh Grang2016-12-061-0/+18
| | | | | | | | | | | | | | Summary: Related llvm patch: https://reviews.llvm.org/D27359 Reviewers: echristo, t.p.northover, rengolin, grosbach, compnerd Subscribers: mehdi_amini, cfe-commits, llvm-commits Tags: #clang-c Differential Revision: https://reviews.llvm.org/D27360 llvm-svn: 288762
* With LTO and profile-use, enable hotness info in opt remarksAdam Nemet2016-12-021-7/+19
| | | | | | | | | | This is to match the behavior of non-LTO; when -fsave-optimization-record is passed and PGO is available we enable the generation of hotness information in the optimization records. Differential Revision: https://reviews.llvm.org/D27332 llvm-svn: 288520
* [CUDA] Forward sanitizer support to host toolchainJason Henline2016-12-021-6/+10
| | | | | | | | | | | | | | | | | | | | Summary: This is an improvement on rL288448 where address sanitization was listed as supported for the CudaToolChain. Since the intent is for the CudaToolChain not to reject any flags supported by the host compiler, this patch switches to forwarding the CudaToolChain sanitizer support to the host toolchain rather than explicitly whitelisting address sanitization. Thanks to hfinkel for this suggestion. Reviewers: jlebar Subscribers: hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D27351 llvm-svn: 288512
* [CUDA] "Support" ASAN arguments in CudaToolChainJason Henline2016-12-022-0/+11
| | | | | | | | | | | | | | | | | | | | | | This fixes a bug that was introduced in rL287285. The bug made it illegal to pass -fsanitize=address during CUDA compilation because the CudaToolChain class was switched from deriving from the Linux toolchain class to deriving directly from the ToolChain toolchain class. When CudaToolChain derived from Linux, it used Linux's getSupportedSanitizers method, and that method allowed ASAN, but when it switched to deriving directly from ToolChain, it inherited a getSupportedSanitizers method that didn't allow for ASAN. This patch fixes that bug by creating a getSupportedSanitizers method for CudaToolChain that supports ASAN. This patch also fixes the test that checks that -fsanitize=address is passed correctly for CUDA builds. That test didn't used to notice if an error message was emitted, and that's why it didn't catch this bug when it was first introduced. With the fix from this patch, that test will now catch any similar bug in the future. llvm-svn: 288448
* [clang] Implement support for -defsym assembler optionMandeep Singh Grang2016-12-011-0/+3
| | | | | | | | | | | | | | | | | Summary: Adds support for -Wa,-defsym,abc=1 option. Related llvm patch: https://reviews.llvm.org/D26214 Reviewers: rafael, t.p.northover, colinl, echristo, compnerd, rengolin Subscribers: mehdi_amini Tags: #clang-c Differential Revision: https://reviews.llvm.org/D26213 llvm-svn: 288397
* Fix crash with unsupported architectures in Linux/Gnu target triples.Florian Hahn2016-12-011-3/+8
| | | | | | | | | | | | Summary: This patch adds a check and an error message to gnutools::Linker::ConstructJob in case the architecture is not supported. For most other operating systems, the error message is created in lib/Basic/Targets.cpp:AllocateTarget, but when construction the linker arguments for the gnutools linker a supported architecture is required. Reviewers: rafael, joerg, echristo Subscribers: mehdi_amini, joerg, dschuff, cfe-commits Differential Revision: https://reviews.llvm.org/D27066 llvm-svn: 288327
* [Driver] Fix recognizing newer OpenSUSE versionsMichal Gorny2016-11-281-2/+5
| | | | | | | | | | Fix recognizing newer OpenSUSE versions that combine the two version components into 'VERSION = x.y'. The check was written against an older version that kept those two split as VERSION and PATCHLEVEL. Differential Revision: https://reviews.llvm.org/D26850 llvm-svn: 288061
* [Driver] Refactor distro detection & classification as a separate APIMichal Gorny2016-11-283-176/+144
| | | | | | | | | | | | Refactor the Distro enum along with helper functions into a full-fledged Distro class, inspired by llvm::Triple, and make it a public API. The new class wraps the enum with necessary comparison operators, adding the convenience Is*() methods and a constructor performing the detection. The public API is needed to run the unit tests (D25869). Differential Revision: https://reviews.llvm.org/D25949 llvm-svn: 288060
* darwin: Unconditionally pass -lto_library, remove -Wliblto warning.Nico Weber2016-11-221-8/+8
| | | | | | | | | | | | | | | | | | | | | 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
* Rename option to -lto-pass-remarks-outputAdam Nemet2016-11-221-1/+1
| | | | | | | The new option -pass-remarks-output broke LLVM_LINK_LLVM_DYLIB because of the duplicate option name with opt. llvm-svn: 287628
* [XRay] Support AArch64 in ClangDean Michael Berris2016-11-211-7/+13
| | | | | | | | | | | | | | | | | | This patch adds XRay support in Clang for AArch64 target. This patch is one of a series: LLVM: https://reviews.llvm.org/D26412 compiler-rt: https://reviews.llvm.org/D26413 Author: rSerge Reviewers: rengolin, dberris Subscribers: aemerson, cfe-commits, iid_iunknown Differential Revision: https://reviews.llvm.org/D26415 llvm-svn: 287518
* LTO support for -fsave-optimization-record on DarwinAdam Nemet2016-11-181-0/+13
| | | | | | | | I guess this would have to be added for each linker. Differential Revision: https://reviews.llvm.org/D26833 llvm-svn: 287358
* Fix a comment for -fsave-optimization-recordAdam Nemet2016-11-181-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D26807 llvm-svn: 287357
* [CUDA] Driver changes to support CUDA compilation on MacOS.Justin Lebar2016-11-184-111/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Compiling CUDA device code requires us to know the host toolchain, because CUDA device-side compiles pull in e.g. host headers. When we only supported Linux compilation, this worked because CudaToolChain, which is responsible for device-side CUDA compilation, inherited from the Linux toolchain. But in order to support MacOS, CudaToolChain needs to take a HostToolChain pointer. Because a CUDA toolchain now requires a host TC, we no longer will create a CUDA toolchain from Driver::getToolChain -- you have to go through CreateOffloadingDeviceToolChains. I am *pretty* sure this is correct, and that previously any attempt to create a CUDA toolchain through getToolChain() would eventually have resulted in us throwing "error: unsupported use of NVPTX for host compilation". In any case hacking getToolChain to create a CUDA+host toolchain would be wrong, because a Driver can be reused for multiple compilations, potentially with different host TCs, and getToolChain will cache the result, causing us to potentially use a stale host TC. So that's the main change in this patch. In addition, we have to pull CudaInstallationDetector out of Generic_GCC and into a top-level class. It's now used by the Generic_GCC and MachO toolchains. Reviewers: tra Subscribers: rryan, hfinkel, sfantao Differential Revision: https://reviews.llvm.org/D26774 llvm-svn: 287285
* [CrashReproducer][Darwin] Suggest attaching .crash diagnostic fileBruno Cardoso Lopes2016-11-171-0/+115
| | | | | | | | | | | | | | | | | | | | | | | In addition to the preprocessed sources file and reproducer script, also point to the .crash diagnostic files on Darwin. Example: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cpp clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.cache clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.sh clang-4.0: note: diagnostic msg: /var/folders/bk/1hj20g8j4xvdj5gd25ywhd3m0000gq/T/RegAllocGreedy-238f28.crash When no match is found for the .crash, point the user to a directory where those can be found. Example: clang-4.0: note: diagnostic msg: Crash backtrace is located in clang-4.0: note: diagnostic msg: /Users/bruno/Library/Logs/DiagnosticReports/clang-4.0_<YYYY-MM-DD-HHMMSS>_<hostname>.crash clang-4.0: note: diagnostic msg: (choose the .crash file that corresponds to your crash) rdar://problem/27286266 llvm-svn: 287262
* Add a little endian variant of TCE.Pekka Jaaskelainen2016-11-163-0/+18
| | | | llvm-svn: 287112
* [Driver] Infer the correct option to ld64 for -fembed-bitcodeSteven Wu2016-11-162-25/+19
| | | | | | | | | | | | | | | | | | Summary: -fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly passed when using LTO. LTO is a special case of -fembed-bitcode which it doesn't require embed the bitcode in a special section in the object file but it requires linker to save that as part of the final executable. rdar://problem/29274226 Reviewers: mehdi_amini Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26690 llvm-svn: 287084
* Revert r286735 due to test failureBrad Smith2016-11-131-4/+0
| | | | llvm-svn: 286736
* Link static PIE programs against rcrt0.o on OpenBSDBrad Smith2016-11-121-0/+4
| | | | | | Patch by Stefan Kempf. llvm-svn: 286735
* Add support of the next Ubuntu (17.04 - Zesty Zapus)Sylvestre Ledru2016-11-121-1/+3
| | | | llvm-svn: 286716
* Tread TSan LLVM flags to driver: add TSan controlling flags to clang.Evgeniy Stepanov2016-11-111-0/+28
| | | | | | | | | | | | | | | | | | Summary: New clang flags, all default to true: -f[no-]sanitize-thread-data-races -f[no-]sanitize-thread-stack-traces -f[no-]sanitize-thread-atomics Reviewers: dvyukov, pcc, eugenis Subscribers: pcc, cfe-commits Patch by Alex Shlyapnikov. Differential Revision: https://reviews.llvm.org/D26461 llvm-svn: 286669
* [cfi] Enable cfi-icall on ARM and AArch64.Evgeniy Stepanov2016-11-111-0/+2
| | | | llvm-svn: 286613
* clang-cl: Pass /Zc:threadSafeInit through to MSVC with /fallback (PR30948)Hans Wennborg2016-11-091-0/+8
| | | | llvm-svn: 286324
* Rename the version of ConstructJob for multiple outputs to ↵Samuel Antao2016-11-034-16/+16
| | | | | | | | ConstructJobMultipleOutputs. It was causing trouble with the GCC bots. llvm-svn: 285925
* [asan] Use the dynamic ASan runtime if -shared-libasan is passedReid Kleckner2016-11-021-1/+2
| | | | | | | | | | -shared-libasan is likely to be used as a link flag if the user is using the GCC-style clang driver. This logic is already tested in clang-cl tests, and the new flag to exercise it will be covered by asan tests. llvm-svn: 285820
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-023-11/+10
| | | | | | | | | | Reviewers: aaron.ballman, mehdi_amini, dblaikie Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D26206 llvm-svn: 285799
* [Modules] Add a command line option for loading the clang builtins modulemap.Elad Cohen2016-10-311-0/+12
| | | | | | | | | -fbuiltin-module-map loads the clang builtins modulemap file. (This is equivalent to -fmodule-map-file=<resource dir>/include/module.modulemap) Differential Revision: https://reviews.llvm.org/D25767 llvm-svn: 285548
* Fix clang installed path to handle case where clang is invoked through a symlinkMehdi Amini2016-10-301-1/+1
| | | | | | | | | | | | | | | | This code path is used when generating the path to libLTO.dylib, which is passed to the linker as `-lto_library'. Without this, if clang is invoked through a symlink, libLTO is searched in a path relative to where the symlink is instead of where clang is actually installed. Fix PR30811. Patch by: Jack Howarth Differential Revision: https://reviews.llvm.org/D26116 llvm-svn: 285525
* Factor finding of libc++ include path out of building -cc1 arguments.Richard Smith2016-10-292-204/+165
| | | | llvm-svn: 285500
* Fix MSVC "not all control paths return a value" warningSimon Pilgrim2016-10-281-0/+2
| | | | | | Add unreachable after enum switch statement llvm-svn: 285390
* [Driver][OpenMP] Add support to create jobs for unbundling actions.Samuel Antao2016-10-275-42/+191
| | | | | | | | | | | | | | | | | | | Summary: This patch adds the support to create jobs for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool to unbundle input files. Unlike other actions, unbundling actions have multiple outputs. Therefore, this patch adds the required changes to have a variant of `Tool::ConstructJob` with multiple outputs. The way the naming of the results is implemented is also slightly modified so that the same action can use a different offloading prefix for each use by the different offloading actions. With this patch, it is possible to compile a functional OpenMP binary with offloading support, even with separate compilation. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21857 llvm-svn: 285326
* [Driver][OpenMP] Add support to create jobs for bundling actions.Samuel Antao2016-10-274-2/+103
| | | | | | | | | | | | Summary: This patch adds the support to create a job for the `OffloadBundlingAction` which will invoke the `clang-offload-bundler` tool. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21856 llvm-svn: 285325
* [Driver][OpenMP] Update actions builder to create unbundling action when ↵Samuel Antao2016-10-274-1/+44
| | | | | | | | | | | | | | | | | necessary. Summary: Each time that offloading support is requested by the user and the input file is not a source file, an action `OffloadUnbundlingAction` is created to signal that the input file may contain bundles, so that the proper tool is then invoked to attempt to extract the components of the bundle. This patch adds the logic to create that action in offload action builder. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21853 llvm-svn: 285324
* [Driver][OpenMP] Update actions builder to create bundling action when ↵Samuel Antao2016-10-273-4/+77
| | | | | | | | | | | | | | | | | necessary. Summary: In order to save the user from dealing with multiple output files (for host and device) while using separate compilation, a new action `OffloadBundlingAction` is used when the last phase is not linking. This action will then result in a job that uses the proposed bundling tool to create a single preprocessed/IR/ASM/Object file from multiple ones. The job creation for the new action will be proposed in a separate patch. Reviewers: echristo, tra, jlebar, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21852 llvm-svn: 285323
* [Driver][OpenMP] Add logic for offloading-specific argument translation.Samuel Antao2016-10-275-21/+74
| | | | | | | | | | | | | | | Summary: This patch includes support for argument translation that is specific of a given offloading kind. Additionally, it implements the translation for OpenMP device kinds in the gcc tool chain. With this patch, it is possible to compile a functional OpenMP application with offloading capabilities with no separate compilation. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21848 llvm-svn: 285320
* [Driver][OpenMP] Build jobs for OpenMP offloading actions for targets using ↵Samuel Antao2016-10-272-34/+210
| | | | | | | | | | | | | | | | | gcc tool chains. Summary: This patch adds logic to create jobs for OpenMP offloading actions by: - tuning the jobs result information to use the offloading prefix even for (device) linking actions. - replacing the device inputs of the host linking jobs by a linker script that embed them in the right sections. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21847 llvm-svn: 285319
* [Driver][OpenMP] Add specialized action builder for OpenMP offloading actions.Samuel Antao2016-10-271-6/+123
| | | | | | | | | | | | | | | | | Summary: This patch adds a new specialized action builder to create OpenMP offloading actions. The specialized builder is added to the action builder already containing the CUDA specialized builder. OpenMP offloading dependences between host and device actions (expressed with OffloadActions) are different that what is used for CUDA: - Device compile action depends on the host compile action - the device frontend extracts the information about the declarations that have to be emitted by looking into the metadata produced by the host frontend. - The host link action depends on the device link actions - the device images are embedded in the host binary at link time. Reviewers: echristo, tra, rsmith, jlebar, ABataev, hfinkel Subscribers: mkuron, whchung, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21845 llvm-svn: 285314
* [Driver][OpenMP] Create tool chains for OpenMP offloading kind.Samuel Antao2016-10-273-67/+101
| | | | | | | | | | | | Summary: This patch adds new logic to create the necessary tool chains to support offloading for OpenMP. The OpenMP related options are checked and the tool chains created accordingly. Diagnostics are emitted in case the options are illegal or express unknown targets. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, mkuron, mehdi_amini, cfe-commits, Hahnfeld, arpith-jacob, carlo.bertolli, caomhin Differential Revision: https://reviews.llvm.org/D21843 llvm-svn: 285311
* [Driver][CUDA][OpenMP] Reimplement tool selection in the driver.Samuel Antao2016-10-271-126/+272
| | | | | | | | | | | | | | | | | Summary: This creates a tool selector in the driver that replaces the existing one. The goal is to better organize the code and make the selector easier to scale, in particular in the presence of offload actions that can be collapsed. The current implementation became more confusing when the support for offloading actions was added. This concern was expressed by Eric in http://reviews.llvm.org/D9888. This patch does not add new testing, it preserves the existing functionality. Reviewers: echristo, tra, jlebar, rsmith, ABataev, hfinkel Subscribers: whchung, guansong, mkuron, mehdi_amini, cfe-commits, Hahnfeld, andreybokhanko, caomhin, arpith-jacob, carlo.bertolli Differential Revision: https://reviews.llvm.org/D21840 llvm-svn: 285307
* [XRay] Check in Clang whether XRay supports the target when ↵Dean Michael Berris2016-10-271-1/+10
| | | | | | | | | | | | | | | -fxray-instrument is passed Summary: Added the code which explicitly emits an error in Clang in case `-fxray-instrument` is passed, but XRay is not supported for the selected target. Reviewers: rsmith, aaron.ballman, rnk, dberris Differential Revision: https://reviews.llvm.org/D24799 llvm-svn: 285266
* Remove check for -o option in offloading actions builder.Samuel Antao2016-10-271-18/+1
| | | | | | This check is also present when jobs are built, so the offloading builder check is not needed anymore. llvm-svn: 285264
* Fix bug when compiling CUDA code with -emit-llvm and -o. Samuel Antao2016-10-271-0/+5
| | | | | | | In this case the device code is not injected into an host action and therefore the user should get an error as -o can't be used when generating two outputs. llvm-svn: 285263
* Unconditionally pass `-lto_library` to the linker on DarwinMehdi Amini2016-10-261-15/+15
| | | | | | | | | | | 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
* [Myriad] Find libc++ adjacent to libstdc++Douglas Katzman2016-10-252-10/+13
| | | | llvm-svn: 285140
* Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.Stephen Hines2016-10-251-0/+8
| | | | | | | | | | | | | | | | Summary: This is only forced on if there is no non-Cortex-A53 CPU specified as well. Android's platform and NDK builds need to assume that the code can be run on Cortex-A53 devices, so we always enable the fix unless we know specifically that the code is only running on a different kind of CPU. Reviewers: cfe-commits Subscribers: aemerson, rengolin, tberghammer, pirama, danalbert Differential Revision: https://reviews.llvm.org/D25761 llvm-svn: 285127
OpenPOWER on IntegriCloud