summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains
Commit message (Collapse)AuthorAgeFilesLines
* [clang] [Driver] [NetBSD] Append -rpath for shared compiler-rt runtimesMichal Gorny2019-01-301-0/+7
| | | | | | | | | | | | Append appropriate -rpath when using shared compiler-rt runtimes, e.g. '-fsanitize=address -shared-libasan'. There's already a similar logic in CommonArgs.cpp but it uses non-standard arch-suffixed installation directory while we want our driver to work with standard installation paths. Differential Revision: https://reviews.llvm.org/D57303 llvm-svn: 352610
* Rollback unwindlib patch.Sterling Augustine2019-01-291-58/+28
| | | | llvm-svn: 352524
* Add --unwindlib=[libgcc|compiler-rt] to parallel --rtlib=Sterling Augustine2019-01-281-28/+58
| | | | | | | | | | | | | | | | 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
* Add -fapply-global-visibility-to-externs for -cc1Scott Linder2019-01-282-1/+4
| | | | | | | | | | | | | Introduce an option to request global visibility settings be applied to declarations without a definition or an explicit visibility, rather than the existing behavior of giving these default visibility. When the visibility of all or most extern definitions are known this allows for the same optimisations -fvisibility permits without updating source code to annotate all declarations. Differential Revision: https://reviews.llvm.org/D56868 llvm-svn: 352391
* Revert r352181 as it's breaking the botsAnton Korobeynikov2019-01-251-4/+0
| | | | llvm-svn: 352186
* Disable PIC/PIE for MSP430 target by default.Anton Korobeynikov2019-01-251-0/+4
| | | | | | | | | | Relocatable code generation is meaningless on MSP430, as the platform is too small to use shared libraries. Patch by Dmitry Mikushev! Differential Revision: https://reviews.llvm.org/D56927 llvm-svn: 352181
* [Driver] Don't pass default value to getCompilerRTArgStringPetr Hosek2019-01-214-7/+7
| | | | | | | | Using static library is already a default. Differential Revision: https://reviews.llvm.org/D56043 llvm-svn: 351710
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1987-348/+261
| | | | | | | | | | | | | | | | | 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
* [mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'Vladimir Stefanovic2019-01-181-0/+8
| | | | | | | | | | | These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along with PIC calls. The linker may then try to turn PIC calls into direct jumps. By default, these fixups do get emitted by the backend, use '-mno-relax-pic-calls' to omit them. Differential revision: https://reviews.llvm.org/D56878 llvm-svn: 351579
* Enable IAS for OpenBSD SPARC.Brad Smith2019-01-151-1/+1
| | | | llvm-svn: 351245
* [Nios2] Remove Nios2 backendCraig Topper2019-01-151-19/+0
| | | | | | | | As mentioned here http://lists.llvm.org/pipermail/llvm-dev/2019-January/129121.html This backend is incomplete and has not been maintained in several months. Differential Revision: https://reviews.llvm.org/D56690 llvm-svn: 351230
* [MSP430] Provide a toolchain descriptionAnton Korobeynikov2019-01-154-0/+341
| | | | | | | | | | | | | | | This is an initial implementation for msp430 toolchain including -mmcu option support -mhwmult options support -integrated-as by default The toolchain uses msp430-elf-as as a linker and supports msp430-gcc toolchain tree. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56658 llvm-svn: 351228
* [Solaris] Move enabling IAS for SPARC from the Solaris toolchain to Generic_GCC.Brad Smith2019-01-152-2/+6
| | | | llvm-svn: 351217
* [WebAssembly] Support multilibs for wasm32 and add a wasm OS that uses itDan Gohman2019-01-151-3/+35
| | | | | | | | | | | | This adds support for multilib paths for wasm32 targets, following [Debian's Multiarch conventions], and also adds an experimental OS name in order to test it. [Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/ Differential Revision: https://reviews.llvm.org/D56553 llvm-svn: 351164
* [NetBSD] Enable additional sanitizer typesMichal Gorny2019-01-121-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D56607 llvm-svn: 351002
* [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTOSteven Wu2019-01-111-7/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: After r327851, Driver::GetTemporaryPath will create the file rather than just create a potientially unqine filename. If clang driver pass the file as parameter as -object_path_lto, ld64 will pass it back to libLTO as GeneratedObjectsDirectory, which is going to cause a LLVM ERROR if it is not a directory. Now during thinLTO, pass a temp directory path to linker instread. rdar://problem/47194182 Reviewers: arphaman, dexonsmith Reviewed By: arphaman Subscribers: mehdi_amini, inglorion, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D56608 llvm-svn: 350970
* [LTO] Add option to enable LTOUnit splitting, and disable unless neededTeresa Johnson2019-01-111-0/+11
| | | | | | | | | | | | | | | | | | | | Summary: Adds a new -f[no]split-lto-unit flag that is disabled by default to control module splitting during ThinLTO. It is automatically enabled for -fsanitize=cfi and -fwhole-program-vtables. The new EnableSplitLTOUnit codegen flag is passed down to llvm via a new module flag of the same name. Depends on D53890. Reviewers: pcc Subscribers: ormris, mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D53891 llvm-svn: 350949
* Properly support -shared-libgcc.Sterling Augustine2019-01-101-6/+3
| | | | | | This revision was revied in D55016. llvm-svn: 350900
* [HIP] Use nul instead of /dev/null when running on windowsYaxun Liu2019-01-101-1/+7
| | | | | | | | When clang is running on windows, /dev/null is not available. Use nul as empty input file instead. Differential Revision: https://reviews.llvm.org/D56225 llvm-svn: 350885
* [OpenMP] Add flag for preventing the extension to 64 bits for the collapse ↵Gheorghe-Teodor Bercea2019-01-091-0/+4
| | | | | | | | | | | | | | | | loop counter Summary: Introduce a compiler flag for cases when the user knows that the collapsed loop counter can be safely represented using at most 32 bits. This will prevent the emission of expensive mathematical operations (such as the div operation) on the iteration variable using 64 bits where 32 bit operations are sufficient. Reviewers: ABataev, caomhin Reviewed By: ABataev Subscribers: hfinkel, kkwli0, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D55928 llvm-svn: 350758
* [Driver] Fix libcxx detection on Darwin with clang run as ./clangIlya Biryukov2019-01-091-4/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: By using '..' instead of fs::parent_path. The intention of the code was to go from 'path/to/clang/bin' to 'path/to/clang/include'. In most cases parent_path works, however it would fail when clang is run as './clang'. This was noticed in Chromium's bug tracker, see https://bugs.chromium.org/p/chromium/issues/detail?id=919761 Reviewers: arphaman, thakis, EricWF Reviewed By: arphaman, thakis Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D56446 llvm-svn: 350714
* [Driver] Default to -fno-addrsig on Android.Dan Albert2019-01-081-0/+1
| | | | | | | | | | | | | | Summary: The Android NDK still uses GNU binutils by default. Reviewers: srhines, pirama Reviewed By: srhines Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56456 llvm-svn: 350668
* [Driver] Disable -faddrsig on Gentoo by defaultMichal Gorny2018-12-231-0/+2
| | | | | | | | | | | | | | Gentoo supports combining clang toolchain with GNU binutils, and many users actually do that. As -faddrsig is not supported by GNU strip, this results in a lot of warnings. Disable it by default and let users enable it explicitly if they want it; with the intent of reevaluating when the underlying feature becomes standarized. See also: https://bugs.gentoo.org/667854 Differential Revision: https://reviews.llvm.org/D56047 llvm-svn: 350028
* [driver] [analyzer] Fix --analyze -Xanalyzer after r349863.Artem Dergachev2018-12-211-2/+13
| | | | | | | | | | | | | | If an -analyzer-config is passed through -Xanalyzer, it is not found while looking for -Xclang. Additionally, don't emit -analyzer-config-compatibility-mode for *every* -analyzer-config flag we encounter; one is enough. https://reviews.llvm.org/D55823 rdar://problem/46504165 llvm-svn: 349866
* Revert "Revert "[driver] [analyzer] Fix a backward compatibility issue after ↵George Karpenkov2018-12-211-3/+7
| | | | | | | | | | r348038."" This reverts commit 144927939587b790c0536f4ff08245043fc8d733. Fixes the bug in the original commit. llvm-svn: 349863
* Revert "[driver] [analyzer] Fix a backward compatibility issue after r348038."Artem Dergachev2018-12-201-10/+3
| | | | | | | | | | | | This reverts commits r349824, r349828, r349835. More buildbot failures were noticed. Differential Revision: https://reviews.llvm.org/D55823 rdar://problem/46504165 llvm-svn: 349843
* [driver] [analyzer] Fix a backward compatibility issue after r348038.Artem Dergachev2018-12-201-3/+10
| | | | | | | | | | | | | | | | | | | Since r348038 we emit an error every time an -analyzer-config option is not found. The driver, however, suppresses this error with another flag, -analyzer-config-compatibility-mode, so backwards compatibility is maintained, while analyzer developers still enjoy the new typo-free experience. The backwards compatibility turns out to be still broken when the -analyze action is not specified; it is still possible to specify -analyzer-config in that case. This should be fixed now. Patch by Kristóf Umann! Differential Revision: https://reviews.llvm.org/D55823 rdar://problem/46504165 llvm-svn: 349824
* [Driver] Fix accidentally reversed condition in r349752Michal Gorny2018-12-201-1/+1
| | | | llvm-svn: 349754
* Replace getOS() == llvm::Triple::*BSD with isOS*BSD() [NFCI]Michal Gorny2018-12-204-20/+20
| | | | | | | | | | | | Replace multiple comparisons of getOS() value with FreeBSD, NetBSD, OpenBSD and DragonFly with matching isOS*BSD() methods. This should improve the consistency of coding style without changing the behavior. Direct getOS() comparisons were left whenever used in switch or switch- like context. Differential Revision: https://reviews.llvm.org/D55916 llvm-svn: 349752
* Disable -faddsig by default for PS4 target.Douglas Yung2018-12-191-0/+1
| | | | llvm-svn: 349691
* [Driver] [NetBSD] Add -D_REENTRANT when using sanitizersMichal Gorny2018-12-192-0/+12
| | | | | | | | | | | | | | | NetBSD intends to support only reentrant interfaces in interceptors. When -lpthread is used without _REENTRANT defined, things are not guaranteed to work. This is especially important for <stdio.h> and sanitization of interfaces around FILE. Some APIs have alternative modes depending on the _REENTRANT definition, and NetBSD intends to support sanitization of the _REENTRANT ones. Differential Revision: https://reviews.llvm.org/D55654 llvm-svn: 349650
* [Driver] Disable -faddrsig by default on NetBSDMichal Gorny2018-12-191-1/+2
| | | | | | | | | | Avoid passing -faddrsig by default on NetBSD. This platform is still using old GNU binutils that crashes on executables containing those sections. Differential Revision: https://reviews.llvm.org/D55828 llvm-svn: 349647
* [Driver][PS4] Do not implicitly link against asan or ubsan if -nostdlib or ↵Pierre Gousseau2018-12-182-3/+6
| | | | | | | | | | | | -nodefaultlibs on PS4. NFC for targets other than PS4. Respect -nostdlib and -nodefaultlibs when enabling asan or ubsan. Differential Revision: https://reviews.llvm.org/D55712 llvm-svn: 349508
* [PowerPC] Make no-PIC default to match GCC - CLANGStefan Pintilie2018-12-181-1/+1
| | | | | | | | Make -fno-PIC default on PowerPC for Little Endian Linux. Differential Revision: https://reviews.llvm.org/D53384 llvm-svn: 349489
* [Driver] Automatically enable -munwind-tables if -fseh-exceptions is enabledMartin Storsjo2018-12-181-0/+6
| | | | | | | | | | | | For targets where SEH exceptions are used by default (on MinGW, only x86_64 so far), -munwind-tables are added automatically. If -fseh-exeptions is enabled on a target where SEH exeptions are availble but not enabled by default yet (aarch64), we need to pass -munwind-tables if -fseh-exceptions was specified. Differential Revision: https://reviews.llvm.org/D55749 llvm-svn: 349452
* Automatic variable initializationJF Bastien2018-12-181-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add an option to initialize automatic variables with either a pattern or with zeroes. The default is still that automatic variables are uninitialized. Also add attributes to request uninitialized on a per-variable basis, mainly to disable initialization of large stack arrays when deemed too expensive. This isn't meant to change the semantics of C and C++. Rather, it's meant to be a last-resort when programmers inadvertently have some undefined behavior in their code. This patch aims to make undefined behavior hurt less, which security-minded people will be very happy about. Notably, this means that there's no inadvertent information leak when: - The compiler re-uses stack slots, and a value is used uninitialized. - The compiler re-uses a register, and a value is used uninitialized. - Stack structs / arrays / unions with padding are copied. This patch only addresses stack and register information leaks. There's many more infoleaks that we could address, and much more undefined behavior that could be tamed. Let's keep this patch focused, and I'm happy to address related issues elsewhere. To keep the patch simple, only some `undef` is removed for now, see `replaceUndef`. The padding-related infoleaks are therefore not all gone yet. This will be addressed in a follow-up, mainly because addressing padding-related leaks should be a stand-alone option which is implied by variable initialization. There are three options when it comes to automatic variable initialization: 0. Uninitialized This is C and C++'s default. It's not changing. Depending on code generation, a programmer who runs into undefined behavior by using an uninialized automatic variable may observe any previous value (including program secrets), or any value which the compiler saw fit to materialize on the stack or in a register (this could be to synthesize an immediate, to refer to code or data locations, to generate cookies, etc). 1. Pattern initialization This is the recommended initialization approach. Pattern initialization's goal is to initialize automatic variables with values which will likely transform logic bugs into crashes down the line, are easily recognizable in a crash dump, without being values which programmers can rely on for useful program semantics. At the same time, pattern initialization tries to generate code which will optimize well. You'll find the following details in `patternFor`: - Integers are initialized with repeated 0xAA bytes (infinite scream). - Vectors of integers are also initialized with infinite scream. - Pointers are initialized with infinite scream on 64-bit platforms because it's an unmappable pointer value on architectures I'm aware of. Pointers are initialize to 0x000000AA (small scream) on 32-bit platforms because 32-bit platforms don't consistently offer unmappable pages. When they do it's usually the zero page. As people try this out, I expect that we'll want to allow different platforms to customize this, let's do so later. - Vectors of pointers are initialized the same way pointers are. - Floating point values and vectors are initialized with a negative quiet NaN with repeated 0xFF payload (e.g. 0xffffffff and 0xffffffffffffffff). NaNs are nice (here, anways) because they propagate on arithmetic, making it more likely that entire computations become NaN when a single uninitialized value sneaks in. - Arrays are initialized to their homogeneous elements' initialization value, repeated. Stack-based Variable-Length Arrays (VLAs) are runtime-initialized to the allocated size (no effort is made for negative size, but zero-sized VLAs are untouched even if technically undefined). - Structs are initialized to their heterogeneous element's initialization values. Zero-size structs are initialized as 0xAA since they're allocated a single byte. - Unions are initialized using the initialization for the largest member of the union. Expect the values used for pattern initialization to change over time, as we refine heuristics (both for performance and security). The goal is truly to avoid injecting semantics into undefined behavior, and we should be comfortable changing these values when there's a worthwhile point in doing so. Why so much infinite scream? Repeated byte patterns tend to be easy to synthesize on most architectures, and otherwise memset is usually very efficient. For values which aren't entirely repeated byte patterns, LLVM will often generate code which does memset + a few stores. 2. Zero initialization Zero initialize all values. This has the unfortunate side-effect of providing semantics to otherwise undefined behavior, programs therefore might start to rely on this behavior, and that's sad. However, some programmers believe that pattern initialization is too expensive for them, and data might show that they're right. The only way to make these programmers wrong is to offer zero-initialization as an option, figure out where they are right, and optimize the compiler into submission. Until the compiler provides acceptable performance for all security-minded code, zero initialization is a useful (if blunt) tool. I've been asked for a fourth initialization option: user-provided byte value. This might be useful, and can easily be added later. Why is an out-of band initialization mecanism desired? We could instead use -Wuninitialized! Indeed we could, but then we're forcing the programmer to provide semantics for something which doesn't actually have any (it's uninitialized!). It's then unclear whether `int derp = 0;` lends meaning to `0`, or whether it's just there to shut that warning up. It's also way easier to use a compiler flag than it is to manually and intelligently initialize all values in a program. Why not just rely on static analysis? Because it cannot reason about all dynamic code paths effectively, and it has false positives. It's a great tool, could get even better, but it's simply incapable of catching all uses of uninitialized values. Why not just rely on memory sanitizer? Because it's not universally available, has a 3x performance cost, and shouldn't be deployed in production. Again, it's a great tool, it'll find the dynamic uses of uninitialized variables that your test coverage hits, but it won't find the ones that you encounter in production. What's the performance like? Not too bad! Previous publications [0] have cited 2.7 to 4.5% averages. We've commmitted a few patches over the last few months to address specific regressions, both in code size and performance. In all cases, the optimizations are generally useful, but variable initialization benefits from them a lot more than regular code does. We've got a handful of other optimizations in mind, but the code is in good enough shape and has found enough latent issues that it's a good time to get the change reviewed, checked in, and have others kick the tires. We'll continue reducing overheads as we try this out on diverse codebases. Is it a good idea? Security-minded folks think so, and apparently so does the Microsoft Visual Studio team [1] who say "Between 2017 and mid 2018, this feature would have killed 49 MSRC cases that involved uninitialized struct data leaking across a trust boundary. It would have also mitigated a number of bugs involving uninitialized struct data being used directly.". They seem to use pure zero initialization, and claim to have taken the overheads down to within noise. Don't just trust Microsoft though, here's another relevant person asking for this [2]. It's been proposed for GCC [3] and LLVM [4] before. What are the caveats? A few! - Variables declared in unreachable code, and used later, aren't initialized. This goto, Duff's device, other objectionable uses of switch. This should instead be a hard-error in any serious codebase. - Volatile stack variables are still weird. That's pre-existing, it's really the language's fault and this patch keeps it weird. We should deprecate volatile [5]. - As noted above, padding isn't fully handled yet. I don't think these caveats make the patch untenable because they can be addressed separately. Should this be on by default? Maybe, in some circumstances. It's a conversation we can have when we've tried it out sufficiently, and we're confident that we've eliminated enough of the overheads that most codebases would want to opt-in. Let's keep our precious undefined behavior until that point in time. How do I use it: 1. On the command-line: -ftrivial-auto-var-init=uninitialized (the default) -ftrivial-auto-var-init=pattern -ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 2. Using an attribute: int dont_initialize_me __attribute((uninitialized)); [0]: https://users.elis.ugent.be/~jsartor/researchDocs/OOPSLA2011Zero-submit.pdf [1]: https://twitter.com/JosephBialek/status/1062774315098112001 [2]: https://outflux.net/slides/2018/lss/danger.pdf [3]: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00615.html [4]: https://github.com/AndroidHardeningArchive/platform_external_clang/commit/776a0955ef6686d23a82d2e6a3cbd4a6a882c31c [5]: http://wg21.link/p1152 I've also posted an RFC to cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060172.html <rdar://problem/39131435> Reviewers: pcc, kcc, rsmith Subscribers: JDevlieghere, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D54604 llvm-svn: 349442
* Update Microsoft name mangling scheme for exception specifiers in the type ↵Reid Kleckner2018-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | system Summary: The msvc exception specifier for noexcept function types has changed from the prior default of "Z" to "_E" if the function cannot throw when compiling with /std:C++17. Patch by Zachary Henkel! Reviewers: zturner, rnk Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55685 llvm-svn: 349414
* [darwin][arm64] use the "cyclone" CPU for Darwin even when `-arch`Alex Lorenz2018-12-174-14/+25
| | | | | | | | | | | | | | | | is not specified The -target option allows the user to specify the build target using LLVM triple. The triple includes the arch, and so the -arch option is redundant. This should work just as well without the -arch. However, the driver has a bug in which it doesn't target the "Cyclone" CPU for darwin if -target is used without -arch. This commit fixes this issue. rdar://46743182 Differential Revision: https://reviews.llvm.org/D55731 llvm-svn: 349382
* [Driver] Don't override '-march' when using '-arch x86_64h'Francis Visoiu Mistrih2018-12-172-10/+2
| | | | | | | | | | | | On Darwin, using '-arch x86_64h' would always override the option passed through '-march'. This patch allows users to use '-march' with x86_64h, while keeping the default to 'core-avx2' Differential Revision: https://reviews.llvm.org/D55775 llvm-svn: 349381
* [darwin] parse the SDK settings from SDKSettings.json if it exists andAlex Lorenz2018-12-172-29/+92
| | | | | | | | | | | | | | | | | | | | pass in the -target-sdk-version to the compiler and backend This commit adds support for reading the SDKSettings.json file in the Darwin driver. This file is used by the driver to determine the SDK's version, and it uses that information to pass it down to the compiler using the new -target-sdk-version= option. This option is then used to set the appropriate SDK Version module metadata introduced in r349119. Note: I had to adjust the two ast tests as the SDKROOT environment variable on macOS caused SDK version to be picked up for the compilation of source file but not the AST. rdar://45774000 Differential Revision: https://reviews.llvm.org/D55673 llvm-svn: 349380
* Implement -frecord-command-line (-frecord-gcc-switches)Scott Linder2018-12-141-7/+22
| | | | | | | | | | | | | | | | | | | | | | | | Implement options in clang to enable recording the driver command-line in an ELF section. Implement a new special named metadata, llvm.commandline, to support frontends embedding their command-line options in IR/ASM/ELF. This differs from the GCC implementation in some key ways: * In GCC there is only one command-line possible per compilation-unit, in LLVM it mirrors llvm.ident and multiple are allowed. * In GCC individual options are separated by NULL bytes, in LLVM entire command-lines are separated by NULL bytes. The advantage of the GCC approach is to clearly delineate options in the face of embedded spaces. The advantage of the LLVM approach is to support merging multiple command-lines unambiguously, while handling embedded spaces with escaping. Differential Revision: https://reviews.llvm.org/D54487 Clang Differential Revision: https://reviews.llvm.org/D54489 llvm-svn: 349155
* [Driver] Add support for -fembed-bitcode for assembly fileSteven Wu2018-12-121-0/+5
| | | | | | | | | | | | | | | | | | Summary: Handle -fembed-bitcode for assembly inputs. When the input file is assembly, write a marker as "__LLVM,__asm" section. Fix llvm.org/pr39659 Reviewers: compnerd, dexonsmith Reviewed By: compnerd Subscribers: rjmccall, dblaikie, jkorous, cfe-commits Differential Revision: https://reviews.llvm.org/D55525 llvm-svn: 348943
* [mips] Enable using of integrated assembler in all cases.Simon Atanasyan2018-12-121-10/+1
| | | | llvm-svn: 348935
* [CUDA][OPENMP][NVPTX]Improve logic of the debug info support.Alexey Bataev2018-12-123-26/+58
| | | | | | | | | | | | | | | | | | | | | | Summary: Added support for the -gline-directives-only option + fixed logic of the debug info for CUDA devices. If optimization level is O0, then options --[no-]cuda-noopt-device-debug do not affect the debug info level. If the optimization level is >O0, debug info options are used + --no-cuda-noopt-device-debug is used or no --cuda-noopt-device-debug is used, the optimization level for the device code is kept and the emission of the debug directives is used. If the opt level is > O0, debug info is requested + --cuda-noopt-device-debug option is used, the optimization is disabled for the device code + required debug info is emitted. Reviewers: tra, echristo Subscribers: aprantl, guansong, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D51554 llvm-svn: 348930
* Revert "[PowerPC] Make no-PIC default to match GCC - CLANG"Stefan Pintilie2018-12-111-1/+1
| | | | | | This reverts commit rL348299. llvm-svn: 348858
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-103-3/+3
| | | | | | | | | | | | | | 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
* Convert some ObjC msgSends to runtime calls.Pete Cooper2018-12-081-0/+12
| | | | | | | | | | | | | | It is faster to directly call the ObjC runtime for methods such as alloc/allocWithZone instead of sending a message to those functions. This patch adds support for converting messages to alloc/allocWithZone to their equivalent runtime calls. Tests included for the positive case of applying this transformation, negative tests that we ensure we only convert "alloc" to objc_alloc, not "alloc2", and also a driver test to ensure we enable this only for supported runtime versions. Reviewed By: rjmccall https://reviews.llvm.org/D55349 llvm-svn: 348687
* Allow forwarding -fdebug-compilation-dir to cc1asNico Weber2018-12-061-0/+3
| | | | | | | | | | | | | | | | | | | The flag -fdebug-compilation-dir is useful to make generated .o files independent of the path of the build directory, without making the compile command-line dependent on the path of the build directory, like -fdebug-prefix-map requires. This change makes it so that the driver can forward the flag to -cc1as, like it already can for -cc1. We might want to consider making -fdebug-compilation-dir a driver flag in a follow-up. (Since -fdebug-compilation-dir defaults to PWD, it's already possible to get this effect by setting PWD, but explicit compiler flags are better than env vars, because e.g. ninja tracks command lines and reruns commands that change.) Somewhat related to PR14625. Differential Revision: https://reviews.llvm.org/D55377 llvm-svn: 348515
* [CUDA] Fix nvidia-cuda-toolkit detection on UbuntuJoel E. Denny2018-12-061-1/+1
| | | | | | | | | | This just extends D40453 (r319317) to Ubuntu. Reviewed By: Hahnfeld, tra Differential Revision: https://reviews.llvm.org/D55269 llvm-svn: 348504
* [darwin] remove version number check when enabling ↵Alex Lorenz2018-12-061-1/+0
| | | | | | | | | | -fobjc-subscripting-legacy-runtime This subscripting feature actually works on older OS versions anyway. rdar://36287065 llvm-svn: 348448
OpenPOWER on IntegriCloud