summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Rollback unwindlib patch.Sterling Augustine2019-01-291-27/+0
| | | | llvm-svn: 352524
* Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib=Sterling Augustine2019-01-281-0/+27
| | | | | | | | | | | | | | | | Summary: "clang++ hello.cc --rtlib=compiler-rt" now works without specifying additional unwind or exception handling libraries. Reviewers: rsmith Subscribers: srhines, dberris, aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D57128 llvm-svn: 352404
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-1/+1
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* [gcov/Darwin] Ensure external symbols are exported when using an export listVedant Kumar2018-12-031-4/+8
| | | | | | | | | | | | | | Make sure that symbols needed to implement runtime support for gcov are exported when using an export list on Darwin. Without the clang driver exporting these symbols, the linker hides them, resulting in tapi verification failures. rdar://45944768 Differential Revision: https://reviews.llvm.org/D55151 llvm-svn: 348187
* Revert "Reapply: [Driver] Use forward slashes in most linker arguments"Martin Storsjo2018-10-261-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r345370, as it uncovered even more issues in tests with partial/inconsistent path normalization: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/13562 http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/886 http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20994 In particular, these tests seem to have failed: Clang :: CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll Clang :: CodeGen/thinlto-multi-module.ll Clang :: Driver/cuda-external-tools.cu Clang :: Driver/cuda-options.cu Clang :: Driver/hip-toolchain-no-rdc.hip Clang :: Driver/hip-toolchain-rdc.hip Clang :: Driver/openmp-offload-gpu.c At least the Driver tests could potentially be fixed by extending the path normalization to even more places, but the issues with the CodeGen tests are still unknown. In addition, a number of other tests seem to have been broken in other clang dependent tools such as clang-tidy and clangd. llvm-svn: 345372
* Reapply: [Driver] Use forward slashes in most linker argumentsMartin Storsjo2018-10-261-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libtool inspects the output of $CC -v to detect what object files and libraries are linked in by default. When clang is built as a native windows executable, all paths are formatted with backslashes, and the backslashes cause each argument to be enclosed in quotes. The backslashes and quotes break further processing within libtool (which is implemented in shell script, running in e.g. msys) pretty badly. Between unix style pathes (that only work in tools that are linked to the msys runtime, essentially the same as cygwin) and proper windows style paths (with backslashes, that can easily break shell scripts and msys environments), the best compromise is to use windows style paths (starting with e.g. c:) but with forward slashes, which both msys based tools, shell scripts and native windows executables can cope with. This incidentally turns out to be the form of paths that GCC prints out when run with -v on windows as well. This change potentially makes the output from clang -v a bit more inconsistent, but it is isn't necessarily very consistent to begin with. Compared to the previous attempt in SVN r345004, this now does the same transformation on more paths, hopefully on the right set of paths so that all tests pass (previously some tests failed, where path fragments that were required to be identical turned out to use different path separators in different places). This now also is done only for non-windows, or cygwin/mingw targets, to preserve all backslashes for MSVC cases (where the paths can end up e.g. embedded into PDB files. (The transformation function itself, llvm::sys::path::convert_to_slash only has an effect when run on windows.) Differential Revision: https://reviews.llvm.org/D53066 llvm-svn: 345370
* Revert "[Driver] Use forward slashes in most linker arguments"Martin Storsjo2018-10-231-9/+7
| | | | | | | | | | | | This reverts commit r345004, as it broke tests when actually run on windows; see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/763. This broke tests that had captured a variable containing a path with backslashes, which failed to match cases in the output where the path separators had been changed into forward slashes. llvm-svn: 345005
* [Driver] Use forward slashes in most linker argumentsMartin Storsjo2018-10-231-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | libtool inspects the output of $CC -v to detect what object files and libraries are linked in by default. When clang is built as a native windows executable, all paths are formatted with backslashes, and the backslashes cause each argument to be enclosed in quotes. The backslashes and quotes break further processing within libtool (which is implemented in shell script, running in e.g. msys) pretty badly. Between unix style pathes (that only work in tools that are linked to the msys runtime, essentially the same as cygwin) and proper windows style paths (with backslashes, that can easily break shell scripts and msys environments), the best compromise is to use windows style paths (starting with e.g. c:) but with forward slashes, which both msys based tools, shell scripts and native windows executables can cope with. This incidentally turns out to be the form of paths that GCC prints out when run with -v on windows as well. This change potentially makes the output from clang -v a bit more inconsistent, but it is isn't necessarily very consistent to begin with. Differential Revision: https://reviews.llvm.org/D53066 llvm-svn: 345004
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-2/+4
| | | | | | | | | | | | | | | | | | | This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
* [MinGW] Allow using ASanMartin Storsjo2018-10-011-1/+3
| | | | | | | | | | | | | | | | | | Linking to ASan for MinGW is similar to MSVC, but MinGW always links the MSVCRT dynamically, so there is only one of the MSVC cases to consider. When linking to a shared compiler runtime library on MinGW, the suffix of the import library is .dll.a. The existing case of .dll as suffix for windows in general doesn't seem correct (since this is used for linking). As long as callers never actually set the Shared flag, the default static suffix of .lib also worked fine for import libraries as well. Differential Revision: https://reviews.llvm.org/D52538 llvm-svn: 343537
* [modules] Driver support for precompiling a collection of files as a singleRichard Smith2018-09-151-0/+1
| | | | | | action. llvm-svn: 342305
* [Driver] Check normalized triples for multiarch runtime pathPetr Hosek2018-08-221-7/+17
| | | | | | | | | | | | | | | | | | | | Previously we only used target triple as provided which matches the GCC behavior, but it also means that all clients have to be consistent in their spelling of target triples since e.g. x86_64-linux-gnu and x86_64-unknown-linux-gnu will result in Clang driver looking at two different paths when searching for runtime libraries. Unfortunatelly, as it turned out many clients aren't consistent in their spelling of target triples, e.g. many Linux distributions use the shorter spelling but config.guess and rustc insist on using the normalized variant which is causing issues. To avoid having to ship multiple copies of runtimes for different triple spelling or rely on symlinks which are not portable, we should also check the normalized triple when constructing paths for multiarch runtimes. Differential Revision: https://reviews.llvm.org/D50547 llvm-svn: 340471
* Remove trailing spaceFangrui Song2018-07-301-1/+1
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
* Support for multiarch runtimes layoutPetr Hosek2018-06-281-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [Driver] Stop passing -fseh-exceptions for x86_64-windows-msvcShoaib Meenai2018-06-061-2/+0
| | | | | | | | | | | -fseh-exceptions is only meaningful for MinGW targets, and that driver already has logic to pass either -fdwarf-exceptions or -fseh-exceptions as appropriate. -fseh-exceptions is just a no-op for MSVC triples, and passing it to cc1 causes unnecessary confusion. Differential Revision: https://reviews.llvm.org/D47850 llvm-svn: 334145
* Do not enable RTTI with -fexceptions, for PS4Sunil Srivastava2018-05-181-16/+3
| | | | | | | | | | | | | | | | | | | NFC for targets other than PS4. This patch is a change in behavior for PS4, in that PS4 will no longer enable RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default on PS4). RTTI will remain disabled except for types being thrown or caught. Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted, as it is for other targets. This patch removes some PS4 specific code, making the code cleaner. Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the same as the generic x86_64-linux are removed, making the test cleaner. Differential Revision: https://reviews.llvm.org/D46982 llvm-svn: 332784
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-3/+3
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-1/+1
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 331069
* AArch64: Implement support for the shadowcallstack attribute.Peter Collingbourne2018-04-041-1/+2
| | | | | | | | | | | | The implementation of shadow call stack on aarch64 is quite different to the implementation on x86_64. Instead of reserving a segment register for the shadow call stack, we reserve the platform register, x18. Any function that spills lr to sp also spills it to the shadow call stack, a pointer to which is stored in x18. Differential Revision: https://reviews.llvm.org/D45239 llvm-svn: 329236
* Add the -fsanitize=shadow-call-stack flagVlad Tsyrklevich2018-04-031-0/+2
| | | | | | | | | | | | | | | | | Summary: Add support for the -fsanitize=shadow-call-stack flag which causes clang to add ShadowCallStack attribute to functions compiled with that flag enabled. Reviewers: pcc, kcc Reviewed By: pcc, kcc Subscribers: cryptoad, cfe-commits, kcc Differential Revision: https://reviews.llvm.org/D44801 llvm-svn: 329122
* [Driver] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2018-03-201-18/+32
| | | | | | other minor fixes (NFC). llvm-svn: 328044
* Better OpenBSD frontend supportKamil Rytarowski2018-03-031-0/+2
| | | | | | | | | | | | | | | | | | Summary: - Like other *BSD, conditioning certain flags to pass - To prepare future OpenBSD sanitisers. Patch by: David CARLIER Reviewers: dlj, krytarowski, vitalybuka Reviewed By: vitalybuka Subscribers: krytarowski, cfe-commits Differential Revision: https://reviews.llvm.org/D43818 llvm-svn: 326645
* Handle the NetBSD case in ToolChain::getOSLibName()Kamil Rytarowski2018-02-271-0/+2
| | | | | | | | | Return a new CompilerRT Path on NetBSD: "netbsd", instead of getOS(), which returns a string like "netbsd8.9.12". Sponsored by <The NetBSD Foundation> llvm-svn: 326219
* [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on ↵Igor Kudrin2018-02-271-2/+2
| | | | | | | | | | Windows. clang used to require adding an ".exe" suffix when targeting ELF systems on Windows. Differential Revision: https://reviews.llvm.org/D43621 llvm-svn: 326164
* [Sanitizers] Basic Solaris sanitizer support (PR 33274)Alex Shlyapnikov2018-02-051-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch (on top of https://reviews.llvm.org/D35755) provides the clang side necessary to enable the Solaris port of the sanitizers implemented by https://reviews.llvm.org/D40898, https://reviews.llvm.org/D40899, and https://reviews.llvm.org/D40900). A few features of note: * While compiler-rt cmake/base-config-ix.cmake (COMPILER_RT_OS_DIR) places the runtime libs in a tolower(CMAKE_SYSTEM_NAME) directory, clang defaults to the OS part of the target triplet (solaris2.11 in the case at hand). The patch makes them agree on compiler-rt's idea. * While Solaris ld accepts a considerable number of GNU ld options for compatibility, it only does so for the double-dash forms. clang unfortunately is inconsistent here and sometimes uses the double-dash form, sometimes the single-dash one that confuses the hell out of Solaris ld. I've changed the affected places to use the double-dash form that should always work. * As described in https://reviews.llvm.org/D40899, Solaris ld doesn't create the __start___sancov_guards/__stop___sancov_guards labels gld/gold/lld do, so I'm including additional runtime libs into the link that provide them. * One test uses -fstack-protector, but unlike other systems libssp hasn't been folded into Solaris libc, but needs to be linked with separately. * For now, only 32-bit x86 asan is enabled on Solaris. 64-bit x86 should follow, but sparc (which requires additional compiler-rt changes not yet submitted) fails miserably due to a llvmsparc backend limitation: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. However, inside the gcc tree, Solaris/sparc asan works almost as well as x86. Reviewers: rsmith, alekseyshl Reviewed By: alekseyshl Subscribers: jyknight, fedor.sergeev, cfe-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40903 llvm-svn: 324296
* [driver] Set the 'simulator' environment for Darwin when compiling forAlex Lorenz2017-12-071-0/+6
| | | | | | | | | | iOS/tvOS/watchOS simulator rdar://35135215 Differential Revision: https://reviews.llvm.org/D40682 llvm-svn: 320073
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a re-apply of r319294. adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319297
* Revert "Toolchain: Normalize dwarf, sjlj and seh eh"Martell Malone2017-11-291-9/+0
| | | | | | | | This reverts rL319294. The windows sanitizer does not like seh on x86. Will re apply with None type for x86 llvm-svn: 319295
* Toolchain: Normalize dwarf, sjlj and seh ehMartell Malone2017-11-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | adds -fseh-exceptions and -fdwarf-exceptions flags clang will check if the user has specified an exception model flag, in the absense of specifying the exception model clang will then check the driver default and append the model flag for that target to cc1 clang cc1 assumes dwarf is the default if none is passed and -fno-exceptions has a higher priority then specifying the model move __SEH__ macro definitions out of Targets into InitPreprocessor behind the -fseh-exceptions flag move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check remove unused USESEHExceptions from the MinGW Driver fold USESjLjExceptions into a new GetExceptionModel function that gives the toolchain classes more flexibility with eh models Reviewers: rnk, mstorsjo Differential Revision: https://reviews.llvm.org/D39673 llvm-svn: 319294
* [Driver] Make the use of relax relocations a per target optionPetr Hosek2017-11-221-0/+4
| | | | | | | | | | | | | The support for relax relocations is dependent on the linker and different toolchains within the same compiler can be using different linkers some of which may or may not support relax relocations. Give toolchains the option to control whether they want to use relax relocations in addition to the existing (global) build system option. Differential Revision: https://reviews.llvm.org/D39831 llvm-svn: 318816
* [OpenMP] Consistently use cubin extension for nvlinkJonas Hahnfeld2017-11-211-0/+4
| | | | | | | | | | | | This was previously done in some places, but for example not for bundling so that single object compilation with -c failed. In addition cubin was used for all file types during unbundling which is incorrect for assembly files that are passed to ptxas. Tighten up the tests so that we can't regress in that area. Differential Revision: https://reviews.llvm.org/D40250 llvm-svn: 318763
* [ARM] For assembler files recognize -Xassembler or -Wa, -mthumbPeter Smith2017-11-201-5/+24
| | | | | | | | | | | | | | | | | | | | | | The Unified Arm Assembler Language is designed so that the majority of assembler files can be assembled for both Arm and Thumb with the choice made as a compilation option. The way this is done in gcc is to pass -mthumb to the assembler with either -Wa,-mthumb or -Xassembler -mthumb. This change adds support for these options to clang. There is no assembler equivalent of -mno-thumb, -marm or -mno-arm so we don't need to recognize these. Ideally we would do all of the processing in CollectArgsForIntegratedAssembler(). Unfortunately we need to change the triple and at that point it is too late. Instead we look for the option earlier in ComputeLLVMTriple(). Fixes PR34519 Differential Revision: https://reviews.llvm.org/D40127 llvm-svn: 318647
* [WebAssembly] Add crt1.o with calling lldSam Clegg2017-10-271-8/+6
| | | | | | | | | Also, for OS unknown targets like wasm, don't include 'unknown' in the library path. This is a fix for rL316719. Differential Revision: https://reviews.llvm.org/D39354 llvm-svn: 316777
* [WebAssembly] Include libclang_rt.builtins in the standard waySam Clegg2017-10-271-1/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D39218 llvm-svn: 316719
* Driver: use ld64.lld when -fuse-ld=lld for darwinMartell Malone2017-10-151-1/+5
| | | | | | | | | | | | | | | | | | | When using lld on macOS the current level of detection between ld and ld64 forces us to rename lld to ld. For ELF targets we have the ld.lld alias so for MACHO we should have ld64.lld so we can use lld without replacing the system compiler. This also solves the additional issue of cross compiling for MACHO where renaming lld to ld with only target ELF. This is the clang driver component change to use this new alias. Reviewers: ruiu, rnk Differential Revision: https://reviews.llvm.org/D38290 llvm-svn: 315867
* [OpenMP] Fix passing of -m arguments correctlyJonas Hahnfeld2017-10-041-61/+55
| | | | | | | | | | The recent fix in D38258 was wrong: getAuxTriple() only returns non-null values for the CUDA toolchain. That is why the now added test for PPC and X86 failed. Differential Revision: https://reviews.llvm.org/D38372 llvm-svn: 314902
* [OpenMP] Fix passing of -m arguments to device toolchainJonas Hahnfeld2017-09-271-6/+9
| | | | | | | | | | | AuxTriple is not set if host and device share a toolchain. Also, removing an argument modifies the DAL which needs to be returned for future use. (Move tests back to offload-openmp.c as they are not related to GPUs.) Differential Revision: https://reviews.llvm.org/D38258 llvm-svn: 314329
* [OpenMP] Fix memory leak when translating argumentsJonas Hahnfeld2017-09-271-3/+5
| | | | | | | | | | Parsing the argument after -Xopenmp-target allocates memory that needs to be freed. Associate it with the final DerivedArgList after we know which one will be used. Differential Revision: https://reviews.llvm.org/D38257 llvm-svn: 314328
* Fix validation of the -mthread-model flag in the Clang driverJonathan Roelofs2017-09-071-5/+0
| | | | | | | | | | | | | The ToolChain class validates the -mthread-model flag in the constructor which doesn't work correctly since the thread model methods are virtual methods. The check is moved into Clang::ConstructJob() when constructing the internal command line. https://reviews.llvm.org/D37496 Patch by: Ian Tessier! llvm-svn: 312748
* Restore clang_rt library name on i686-android.Evgeniy Stepanov2017-08-291-0/+4
| | | | | | | | | | | | | | | | | Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
* Use class to pass information about executable nameSerge Pavlov2017-08-291-19/+22
| | | | | | | | | | | | | Information about clang executable name components, such as target and driver mode, was passes in std::pair. With this change it is passed in a special structure. It improves readability and makes access to this information more convenient. NFC. Differential Revision: https://reviews.llvm.org/D36057 llvm-svn: 311981
* Reland r311836 - [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-281-4/+1
| | | | | | | | | | | | | | | | | | | | Use llvm::Triple::getArchTypeName() when looking for compiler-rt libraries, rather than the exact arch string from the triple. This is more correct as it matches the values used when building compiler-rt (builtin-config-ix.cmake) which are the subset of the values allowed in triples. For example, this fixes an issue when the compiler set for i686-pc-linux-gnu triple would not find an i386 compiler-rt library, while this is the exact arch that is detected by compiler-rt. The same applies to any other i?86 variant allowed by LLVM. This also makes the special case for MSVC unnecessary, since now i386 will be used reliably for all 32-bit x86 variants. Differential Revision: https://reviews.llvm.org/D26796 llvm-svn: 311923
* Revert r311836 - [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-271-1/+4
| | | | | | | This causes a breakage on the Android build bot. Let's revert it until we figure out the correct solution there. llvm-svn: 311861
* [Driver] Use arch type to find compiler-rt libraries (on Linux)Michal Gorny2017-08-261-4/+1
| | | | | | | | | | | | | | | | | | | | Use llvm::Triple::getArchTypeName() when looking for compiler-rt libraries, rather than the exact arch string from the triple. This is more correct as it matches the values used when building compiler-rt (builtin-config-ix.cmake) which are the subset of the values allowed in triples. For example, this fixes an issue when the compiler set for i686-pc-linux-gnu triple would not find an i386 compiler-rt library, while this is the exact arch that is detected by compiler-rt. The same applies to any other i?86 variant allowed by LLVM. This also makes the special case for MSVC unnecessary, since now i386 will be used reliably for all 32-bit x86 variants. Differential Revision: https://reviews.llvm.org/D26796 llvm-svn: 311836
* Fix memory leak in ToolChain::TranslateOpenMPTargetArgsJonas Hahnfeld2017-08-141-1/+5
| | | | | | | rL310433 introduced a code path where DAL is not returned and must be freed. This change allows to run openmp-offload.c when Clang is built with ASan. llvm-svn: 310817
* [Driver] Search compiler-rt paths in -print-file-name=Petr Hosek2017-08-101-3/+8
| | | | | | | | | | | This makes it possible to print the name of compiler-rt libraries by using simply clang -print-file-name=libclang_rt.${runtime}-${arch}.so same as other libraries, without having to know the details of the resource directory organization. Differential Revision: https://reviews.llvm.org/D35820 llvm-svn: 310548
* [OpenMP] Fix bug regarding cubin integration into host binaryGheorghe-Teodor Bercea2017-08-091-1/+3
| | | | | | | | | | when a BindArchAction is used. This is not a functional change. Original Diff: D29654 llvm-svn: 310433
OpenPOWER on IntegriCloud