summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChain.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* [OpenMP] Add flag for specifying the target device architecture for OpenMP ↵Gheorghe-Teodor Bercea2017-08-071-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | device offloading Summary: OpenMP has the ability to offload target regions to devices which may have different architectures. A new -fopenmp-target-arch flag is introduced to specify the device architecture. In this patch I use the new flag to specify the compute capability of the underlying NVIDIA architecture for the OpenMP offloading CUDA tool chain. Only a host-offloading test is provided since full device offloading capability will only be available when [[ https://reviews.llvm.org/D29654 | D29654 ]] lands. Reviewers: hfinkel, Hahnfeld, carlo.bertolli, caomhin, ABataev Reviewed By: hfinkel Subscribers: guansong, cfe-commits Tags: #openmp Differential Revision: https://reviews.llvm.org/D34784 llvm-svn: 310263
* [Driver] Error if ARM mode was selected explicitly for M-profile CPUs.Florian Hahn2017-08-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: M-class profiles do not support ARM execution mode, so providing -marm/-mno-thumb does not make sense in combination with -mcpu/-march options that support the M-profile. This is a follow-up patch to D35569 and it seemed pretty clear that we should emit an error in the driver in this case. We probably also should warn/error if the provided -mcpu/-march options do not match, e.g. -mcpu=cortex-m0 -march=armv8-a is invalid, as cortex-m0 does not support armv8-a. But that should be a separate patch I think. Reviewers: echristo, richard.barton.arm, rengolin, labrinea, charles.baylis Reviewed By: rengolin Subscribers: aemerson, javed.absar, kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D35826 llvm-svn: 310047
* [Driver][Darwin] Pass -munwind-table when !UseSjLjExceptions.Akira Hatanaka2017-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug where clang/llvm doesn't emit an unwind table for a function when it is marked noexcept. Without this patch, the following code terminates with an uncaught exception on ARM64: int foo1() noexcept { try { throw 0; } catch (int i) { return 0; } return 1; } int main() { return foo1(); } rdar://problem/32411865 Differential Revision: https://reviews.llvm.org/D35693 llvm-svn: 310006
* Update to use enum classes for various ARM *Kind enumsFlorian Hahn2017-07-271-1/+1
| | | | | | | | | | | | | | Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
* Introduce -nostdlib++ flag to disable linking the C++ standard library.Nico Weber2017-07-251-0/+8
| | | | | | | | | | | | | | | Projects that want to statically link their own C++ standard library currently need to pass -nostdlib or -nodefaultlibs, which also disables linking of the builtins library, -lm, and so on. Alternatively, they could use `clang` instead of `clang++`, but that already disables implicit addition of -lm on some toolchains. Add a dedicated flag -nostdlib++ that disables just linking of libc++ / libstdc++. This is analogous to -nostdinc++. https://reviews.llvm.org/D35780 llvm-svn: 308997
* [OpenMP] Extend CLANG target options with device offloading kind.Gheorghe-Teodor Bercea2017-07-061-3/+3
| | | | | | | | | | | | | | Summary: Pass the type of the device offloading when building the tool chain for a particular target architecture. This is required when supporting multiple tool chains that target a single device type. In our particular use case, the OpenMP and CUDA tool chains will use the same ```addClangTargetOptions ``` method. This enables the reuse of common options and ensures control over options only supported by a particular tool chain. Reviewers: arpith-jacob, caomhin, carlo.bertolli, ABataev, jlebar, hfinkel, tstellar, Hahnfeld Reviewed By: hfinkel Subscribers: jgravelle-google, aheejin, rengolin, jfb, dschuff, sbc100, cfe-commits Differential Revision: https://reviews.llvm.org/D29647 llvm-svn: 307272
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-0/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (This is a move-only refactoring patch. There are no functionality changes.) This patch splits apart the Clang driver's tool and toolchain implementation files. Each target platform toolchain is moved to its own file, along with the closest-related tools. Each target platform toolchain has separate headers and implementation files, so the hierarchy of classes is unchanged. There are some remaining shared free functions, mostly from Tools.cpp. Several of these move to their own architecture-specific files, similar to r296056. Some of them are only used by a single target platform; since the tools and toolchains are now together, some helpers now live in a platform-specific file. The balance are helpers related to manipulating argument lists, so they are now in a new file pair, CommonArgs.h and .cpp. I've tried to cluster the code logically, which is fairly straightforward for most of the target platforms and shared architectures. I think I've made reasonable choices for these, as well as the various shared helpers; but of course, I'm happy to hear feedback in the review. There are some particular things I don't like about this patch, but haven't been able to find a better overall solution. The first is the proliferation of files: there are several files that are tiny because the toolchain is not very different from its base (usually the Gnu tools/toolchain). I think this is mostly a reflection of the true complexity, though, so it may not be "fixable" in any reasonable sense. The second thing I don't like are the includes like "../Something.h". I've avoided this largely by clustering into the current file structure. However, a few of these includes remain, and in those cases it doesn't make sense to me to sink an existing file any deeper. Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30372 llvm-svn: 297250
* Add arch-specific directory to search pathPirama Arumuga Nainar2017-03-031-0/+13
| | | | | | | | | | | | | | | | | Summary: This change adds an arch-specific subdirectory in <ResourceDir>/lib/<OS> to the linker search path. This path also gets added as '-rpath' for native compilation if a runtime is linked in as a shared object. This allows arch-specific libraries to be installed alongside clang. Reviewers: danalbert, cbergstrom, javed.absar Subscribers: srhines Differential Revision: https://reviews.llvm.org/D30015 llvm-svn: 296927
* [Driver] Allow setting the default linker during buildPetr Hosek2016-12-141-24/+22
| | | | | | | | | This change allows setting the default linker used by the Clang driver when configuring the build. Differential Revision: https://reviews.llvm.org/D25263 llvm-svn: 289668
* [Driver] Simplify ToolChain::GetCXXStdlibType (NFC)Jonas Hahnfeld2016-12-121-34/+13
| | | | | | | | | | I made the wrong assumption that execution would continue after an error Diag which led to unneeded complex code. This patch aligns with the better implementation of ToolChain::GetRuntimeLibType. Differential Revision: https://reviews.llvm.org/D25669 llvm-svn: 289422
* Refactor how the MSVC toolchain searches for a compatibility version.David L. Jones2016-12-071-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud