summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains
Commit message (Collapse)AuthorAgeFilesLines
* [remark][diagnostics] [codegen] Fix PR44896Rong Xu2020-02-261-1/+9
| | | | | | | | | | | | | | | | | This patch fixes PR44896. For IR input files, option fdiscard-value-names should be ignored as we need named values in loadModule(). Commit 60d3947922 sets this option after loadModule() where valued names already created. This creates an inconsistent state in setNameImpl() that leads to a seg fault. This patch forces fdiscard-value-names to be false for IR input files. This patch also emits a warning of "ignoring -fdiscard-value-names" if option fdiscard-value-names is explictly enabled in the commandline for IR input files. Differential Revision: https://reviews.llvm.org/D74878 (cherry picked from commit 11857d49948b845dcfd7c7f78595095e3add012d)
* Restore functionality of --sysroot on FreeBSD after b18cb9c47Dimitry Andric2020-02-192-6/+15
| | | | | | | | | | | | | | | | | After b18cb9c47, clang would sometimes prefer the host C++ includes (e.g. in /usr/include/c++/v1) before those specified via --sysroot. While this behavior may be desirable on Linux, it is not so on FreeBSD, where we make extensive use of --sysroot during the build of the base system. In that case, clang must *not* search outside the sysroot, except for its own internal headers. Add an override addLibCxxIncludePaths() to restore the old behavior, which is to simply append /usr/include/c++/v1 to the specified sysroot. While here, apply clang-format to the FreeBSD specific toolchain files. Fixes PR44923. (cherry picked from commit 62654cab7e654384ba503d6b62b1054cde19a553)
* [Clang] Limit -fintegrated-cc1 to only one TUAlexandre Ganea2020-02-131-1/+1
| | | | | | | | | | As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode). I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term. Differential Revision: https://reviews.llvm.org/D74490 (cherry picked from commit 20f1abe306d030e99f56185a3aa077ffadf59b8a)
* Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid ↵Alexandre Ganea2020-02-101-0/+5
| | | | | | | | | | | crashing when generating crash diagnostics when '#pragma clang __debug ..." This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076) and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070) The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c. (cherry picked from commit 75f09b54429bee17a96e2ba7a2ac0f0a8a7f7e74)
* [CUDA] Assume the latest known CUDA version if we've found an unknown one.Artem Belevich2020-01-291-28/+15
| | | | | | | | | | | | | | | | | This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-241-4/+7
| | | | | | | | | | __attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072 (cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
* [HIP] use GetProgramPath for executable discoveryHolger Wünsche2020-01-221-15/+8
| | | | | | | | | | | This change replaces the manual building of executable paths using llvm::sys::path::append with GetProgramPath. This enables adding other paths in case executables reside in different directories and makes the code easier to read. Differential Revision: https://reviews.llvm.org/D72903 (cherry picked from commit 24d7a0935bea390fc444f6ac8cf02447fe8d6917)
* Revert "[RISCV] Add Clang frontend support for Bitmanip extension"Scott Egerton2020-01-151-3/+0
| | | | This reverts commit 57cf6ee9c84434161088c39a6f8dd2aae14eb12d.
* [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundariesFangrui Song2020-01-141-2/+55
| | | | | | | | These driver options perform some checking and delegate to MC options -x86-align-branch* and -x86-branches-within-32B-boundaries. Reviewed By: skan Differential Revision: https://reviews.llvm.org/D72463
* [RISCV] Add Clang frontend support for Bitmanip extensionScott Egerton2020-01-141-0/+3
| | | | | | | | | | | | | | Summary: This adds the __riscv_bitmanip macro and the 'b' target feature to enable it. Reviewers: asb, simoncook, lewis-revill, PaoloS, lenary Reviewed By: lenary Subscribers: Jim, rbar, johnrusso, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71553
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-3/+3
|
* [DebugInfo] Add another level to DebugInfoKind called ConstructorAmy Huang2020-01-131-0/+3
| | | | | | | | | The option will limit debug info by only emitting complete class type information when its constructor is emitted. This patch changes comparisons with LimitedDebugInfo to use the new level instead. Differential Revision: https://reviews.llvm.org/D72427
* [Clang] Always set -z now linker option on FuchsiaPetr Hosek2020-01-131-0/+3
| | | | | | This should be the default on Fuchsia. Differential Revision: https://reviews.llvm.org/D70576
* [Clang][Driver] Re-use the calling process instead of creating a new process ↵Alexandre Ganea2020-01-131-0/+4
| | | | | | | | | | | | | | | for the cc1 invocation With this patch, the clang tool will now call the -cc1 invocation directly inside the same process. Previously, the -cc1 invocation was creating, and waiting for, a new process. This patch therefore reduces the number of created processes during a build, thus it reduces build times on platforms where process creation can be costly (Windows) and/or impacted by a antivirus. It also makes debugging a bit easier, as there's no need to attach to the secondary -cc1 process anymore, breakpoints will be hit inside the same process. Crashes or signaling inside the -cc1 invocation will have the same side-effect as before, and will be reported through the same means. This behavior can be controlled at compile-time through the CLANG_SPAWN_CC1 cmake flag, which defaults to OFF. Setting it to ON will revert to the previous behavior, where any -cc1 invocation will create/fork a secondary process. At run-time, it is also possible to tweak the CLANG_SPAWN_CC1 environment variable. Setting it and will override the compile-time setting. A value of 0 calls -cc1 inside the calling process; a value of 1 will create a secondary process, as before. Differential Revision: https://reviews.llvm.org/D69825
* This option allows selecting the TLS size in the local exec TLS model,KAWASHIMA Takahiro2020-01-131-0/+13
| | | | | | | | | | | | | | | | | | which is the default TLS model for non-PIC objects. This allows large/ many thread local variables or a compact/fast code in an executable. Specification is same as that of GCC. For example, the code model option precedes the TLS size option. TLS access models other than local-exec are not changed. It means supoort of the large code model is only in the local exec TLS model. Patch By KAWASHIMA Takahiro (kawashima-fj <t-kawashima@fujitsu.com>) Reviewers: dmgreen, mstorsjo, t.p.northover, peter.smith, ostannard Reviewd By: peter.smith Committed by: peter.smith Differential Revision: https://reviews.llvm.org/D71688
* driver: Allow -fdebug-compilation-dir=foo in joined form.Nico Weber2020-01-101-0/+6
| | | | | | | All 130+ f_Group flags that take an argument allow it after a '=', except for fdebug-complation-dir. Add a Joined<> alias so that it behaves consistently with all the other f_Group flags. (Keep the old Separate flag for backwards compat.)
* [Driver][PowerPC] Move powerpcspe logic from cc1 to DriverFangrui Song2020-01-101-0/+3
| | | | | | | | | Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72433
* [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]Fangrui Song2020-01-101-0/+18
| | | | | | | | | | | In the backend, this feature is implemented with the function attribute "patchable-function-entry". Both the attribute and XRay use TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are incompatible. Reviewed By: ostannard, MaskRay Differential Revision: https://reviews.llvm.org/D72222
* [ARM][MVE] MVE-I should not be disabled by -mfpu=noneMomchil Velikov2020-01-091-20/+23
| | | | | | | | | | | | | | | Architecturally, it's allowed to have MVE-I without an FPU, thus -mfpu=none should not disable MVE-I, or moves to/from FP-registers. This patch removes `+/-fpregs` from features unconditionally added to target feature list, depending on FPU and moves the logic to Clang driver, where the negative form (`-fpregs`) is conditionally added to the target features list for the cases of `-mfloat-abi=soft`, or `-mfpu=none` without either `+mve` or `+mve.fp`. Only the negative form is added by the driver, the positive one is derived from other features in the backend. Differential Revision: https://reviews.llvm.org/D71843
* AArch64: add missing Apple CPU names and use them by default.Tim Northover2020-01-081-4/+5
| | | | | | | | Apple's CPUs are called A7-A13 in official communication, occasionally with weird suffixes which we probably don't need to care about. This adds each one and describes its features. It also switches the default CPU to the canonical name for Cyclone, but leaves legacy support in so that existing bitcode still compiles.
* [PowerPC] Default ppc64 linux-gnu/freebsd to -fno-PICFangrui Song2020-01-071-3/+0
| | | | | | | | | | | | | | | | | According to D53384, the default was switched from -fno-PIC to -fPIC to work around a -fsanitize=leak bug on big-endian. This gratuitous difference between little-endian and big-endian is undesired, and not acceptable on powerpc64-unknown-freebsd. If -fsanitize=leak still has the problem, we should consider defaulting to -fPIC/-fPIE only when -fsanitize=leak is specified (see SanitizerArgs::requiresPIE()) powerpc64-ibm-aix is unaffected: it still defaults to -fPIC. powerpc64-linux-musl is unaffected (-fPIE since D39588): it still defaults to -fPIE. Reviewed By: #powerpc, jhibbits Differential Revision: https://reviews.llvm.org/D72363
* [PowerPC][Triple] Use elfv2 on freebsd>=13 and linux-muslFangrui Song2020-01-071-2/+7
| | | | | | | | | | | | | | | | | | | Summary: Every powerpc64le platform uses elfv2. For powerpc64, the environments "elfv1" and "elfv2" were added for FreeBSD ELFv1->ELFv2 migration in D61950. FreeBSD developers have decided to use OS versions to select ABI, and no one is relying on the environments. Also use elfv2 on powerpc64-linux-musl. Users can always use -mabi=elfv1 and -mabi=elfv2 to override the default ABI. Reviewed By: adalava Differential Revision: https://reviews.llvm.org/D72352
* [HIP] Add option --gpu-max-threads-per-block=nYaxun (Sam) Liu2020-01-071-0/+8
| | | | | | Add this option to change the default launch bounds. Differential Revision: https://reviews.llvm.org/D71221
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-073-15/+7
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* Add Triple::isX86()Fangrui Song2020-01-062-5/+4
| | | | | | Reviewed By: craig.topper, skan Differential Revision: https://reviews.llvm.org/D72247
* [NFC] Test commit, revert whitespace changestevewan2020-01-061-1/+0
| | | | As per the Developer Policy, upon obtaining commit access.
* [NFC] Test commit, whitespace changestevewan2020-01-061-0/+1
| | | | As per the Developer Policy, upon obtaining commit access.
* [Gnu toolchain] Look at standard GCC paths for libstdcxx by defaultKristina Brooks2020-01-056-86/+121
| | | | | | | | | | | Linux' current addLibCxxIncludePaths and addLibStdCxxIncludePaths are actually almost non-Linux-specific at all, and can be reused almost as such for all gcc toolchains. Only keep Android/Freescale/Cray hacks in Linux's version. Patch by sthibaul (Samuel Thibault) Differential Revision: https://reviews.llvm.org/D69758
* [SystemZ] Don't allow CL option -mpacked-stack with -mbackchain.Jonas Paulsson2020-01-031-3/+13
| | | | | | | -mpacked-stack is currently not supported with -mbackchain, so this should result in a compilation error message instead of being silently ignored. Review: Ulrich Weigand
* [Driver] Allow -mnop-mcount for SystemZ and -mfentry for X86 and SystemZFangrui Song2019-12-221-9/+18
| | | | | | | | | | | | | | | | | | | | | | | gcc/config/{i386,s390} support -mnop-mcount. We currently only support -mnop-mcount for SystemZ. The function attribute "mnop-mcount" is ignored on other targets. gcc/config/{i386,s390} support -mfentry. We currently only support -mfentry for X86 and SystemZ. TargetOpcode::FENTRY_CALL is not handled on other targets. % clang -target aarch64 -pg -mfentry a.c -c fatal error: error in backend: Not supported instr: <MCInst 21> -mfentry, -mrecord-mcount, and -mnop-mcount were invented for Linux ftrace. Linux uses $(call cc-option-yn,-mrecord-mcount) to detect if the specific feature is available. Reject unsupported features so that Linux build system will not wrongly consider them available and cause build/runtime failures. Note, GCC has stricter checks that we do not implement, e.g. -fpic/-fpie -fnop-mcount is not allowed on x86, -fpic/-fpie -mfentry is not allowed on x86-32.
* [Driver] Verify -mrecord-mcount in Driver, instead of CodeGen after D71627Fangrui Song2019-12-211-2/+9
| | | | | | | | | | | GCC's x86 and s390 ports support -mrecord-mcount. Other ports reject the option. aarch64-linux-gnu-gcc: error: unrecognized command line option ‘-mrecord-mcount’ Allowing this option can cause failures when building Linux kernel for aarch64, powerpc64, etc, which will think the feature is available if the clang command returns 0.
* [analyzer] Add Fuchsia Handle checkerGabor Horvath2019-12-201-0/+2
| | | | | | | The checker can diagnose handle use after releases, double releases, and handle leaks. Differential Revision: https://reviews.llvm.org/D70470
* Avoid unsupported LLD optionsSid Manning2019-12-201-3/+8
| | | | Differential Revision: https://reviews.llvm.org/D70919
* [analyzer] Add a syntactic security check for ObjC NSCoder API.Artem Dergachev2019-12-191-1/+4
| | | | | | | Method '-[NSCoder decodeValueOfObjCType:at:]' is not only deprecated but also a security hazard, hence a loud check. Differential Revision: https://reviews.llvm.org/D71728
* [Clang FE, SystemZ] Recognize -mrecord-mcount CL option.Jonas Paulsson2019-12-191-0/+3
| | | | | | | | | | Recognize -mrecord-mcount from the command line and add a function attribute "mrecord-mcount" when passed. Only valid on SystemZ (when used with -mfentry). Review: Ulrich Weigand https://reviews.llvm.org/D71627
* Re-land "Add an -fno-temp-file flag for compilation"Hans Wennborg2019-12-191-0/+1
| | | | | | | | This time making sure to initialize FrontendOptions::UseTemporary. Patch by Zachary Henkel! Differential revision: https://reviews.llvm.org/D70615
* [clang] Remove -Wexperimental-float-control.Jordan Rupprecht2019-12-181-8/+0
| | | | | | | | | | | | | | Summary: Per D62731, the behavior of clang with `-frounding-math` is no worse than when the rounding flag was completely ignored, so remove this unnecessary warning. Reviewers: mibintc, chandlerc, echristo, rjmccall, kpn, erichkeane, rsmith, andrew.w.kaylor Reviewed By: mibintc Subscribers: merge_guards_bot, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71671
* [Remarks][Driver] Place temporary remark files next to temporary object filesFrancis Visoiu Mistrih2019-12-181-11/+18
| | | | | | | | | | | On Darwin, when used for generating a linked binary from a source file (through an intermediate object file), the driver will invoke `cc1` to generate a temporary object file. The temporary remark file will now be emitted next to the object file, which will then be picked up by `dsymutil` and emitted in the .dSYM bundle. This is available for all formats except YAML since by default, YAML doesn't need a section and the remark file will be lost.
* [Remarks][Driver][NFC] Make shouldEmitRemarks more available in the DriverFrancis Visoiu Mistrih2019-12-181-25/+2
| | | | Move the function to Driver.h so that it can be re-used in other places.
* Revert "Add an -fno-temp-file flag for compilation"Mitch Phillips2019-12-181-1/+0
| | | | | | | This reverts commit d129aa1d5369781deff6c6b854cb612e160d3fb2. This broke the MSan buildbots. More information available in the original PR: https://reviews.llvm.org/D70615
* Add an -fno-temp-file flag for compilationHans Wennborg2019-12-181-0/+1
| | | | | | | | | | | | Our build system does not handle randomly named files created during the build well. We'd prefer to write compilation output directly without creating a temporary file. Function parameters already existed to control this behavior but were not exposed all the way out to the command line. Patch by Zachary Henkel! Differential revision: https://reviews.llvm.org/D70615
* [Clang FE, SystemZ] Recognize -mpacked-stack CL optionJonas Paulsson2019-12-171-0/+2
| | | | | | | | | | | Recognize -mpacked-stack from the command line and add a function attribute "mpacked-stack" when passed. This is needed for building the Linux kernel. If this option is passed for any other target than SystemZ, an error is generated. Review: Ulrich Weigand https://reviews.llvm.org/D71441
* [driver][darwin] Pass -platform_version flag to the linker instead of the ↵Alex Lorenz2019-12-172-1/+50
| | | | | | | | | | | -<platform>_version_min flag In Xcode 11, ld added a new flag called -platform_version that can be used instead of the old -<platform>_version_min flags. The new flag allows Clang to pass the SDK version from the driver to the linker. This patch adopts the new -platform_version flag in Clang, and starts using it by default, unless a linker version < 520 is passed to the driver. Differential Revision: https://reviews.llvm.org/D71579
* [MinGW] Implicitly add .exe suffix if not providedMartin Storsjö2019-12-171-1/+13
| | | | | | | | | | | | | | | | | GCC implicitly adds an .exe suffix if it is given an output file name, but the file name doesn't contain a suffix, and there are certain users of GCC that rely on this behaviour (and run into issues when trying to use Clang instead of GCC). And MSVC's cl.exe also does the same (but not link.exe). However, GCC only does this when actually running on windows, not when operating as a cross compiler. As GCC doesn't have this behaviour when cross compiling, we definitely shouldn't introduce the behaviour in such cases (as it would break at least as many cases as this fixes). Differential Revision: https://reviews.llvm.org/D71400
* [clang][SystemZ] Add support for -march=nativeUlrich Weigand2019-12-163-5/+18
| | | | | | Handle -march=native in systemz::getSystemZTargetCPU, similar to how this is done on other platforms. Also change the return type to std::string instead of const char *.
* [Driver] Default to -momit-leaf-frame-pointer for AArch64Fangrui Song2019-12-131-3/+3
| | | | | | | | | | | | | | | | | This matches https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html > -momit-leaf-frame-pointer > -mno-omit-leaf-frame-pointer > > Omit or keep the frame pointer in leaf functions. The former behavior is the default. -mno-omit-leaf-frame-pointer is currently a no-op because TargetOptions::DisableFramePointerElim is only considered for non-leaf functions. Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D71167
* [Driver] Use .init_array for all gcc installations and simplify Generic_ELF ↵Fangrui Song2019-12-133-17/+14
| | | | | | | | | | | | | | | | | -fno-use-init-array rules D39317 made clang use .init_array when no gcc installations is found. This change changes all gcc installations to use .init_array . GCC 4.7 by default stopped providing .ctors/.dtors compatible crt files, and stopped emitting .ctors for __attribute__((constructor)). .init_array should always work. FreeBSD rules are moved to FreeBSD.cpp to make Generic_ELF rules clean. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71434
* Default to -fuse-init-arrayFangrui Song2019-12-128-14/+27
| | | | | | | | | | | | | | | | | | | Very few ELF platforms still use .ctors/.dtors now. Linux (glibc: 1999-07), DragonFlyBSD, FreeBSD (2012-03) and Solaris have supported .init_array for many years. Some architectures like AArch64/RISC-V default to .init_array . GNU ld and gold can even convert .ctors to .init_array . It makes more sense to flip the CC1 default, and only uses -fno-use-init-array on platforms that don't support .init_array . For example, OpenBSD did not support DT_INIT_ARRAY before Aug 2016 (https://github.com/openbsd/src/commit/86fa57a2792c6374b0849dd7b818a11e676e60ba) I may miss some ELF platforms that still use .ctors, but their maintainers can easily diagnose such problems. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71393
* [Remarks][Driver] Ask for line tables when remarks are enabledFrancis Visoiu Mistrih2019-12-111-0/+5
| | | | | | | | | | | | | | | | Serialized remarks contain debug locations for each remark, by storing a file path, a line, and a column. Also, remarks support being embedded in a .dSYM bundle using a separate section in object files, that is found by `dsymutil` through the debug map. In order for tools to map addresses to source and display remarks in the source, we need line tables, and in order for `dsymutil` to find the object files containing the remark section, we need to keep the debug map around. Differential Revision: https://reviews.llvm.org/D71325
* [OpenMP] Use the OpenMP-IR-BuilderJohannes Doerfert2019-12-111-0/+1
| | | | | | | | | | | | | | | This is a follow up patch to use the OpenMP-IR-Builder, as discussed on the mailing list ([1] and later) and at the US Dev Meeting'19. [1] http://lists.flang-compiler.org/pipermail/flang-dev_lists.flang-compiler.org/2019-May/000197.html Reviewers: kiranchandramohan, ABataev, RaviNarayanaswamy, gtbercea, grokos, sdmitriev, JonChesterfield, hfinkel, fghanim Subscribers: ppenzin, penzn, llvm-commits, cfe-commits, jfb, guansong, bollu, hiraditya, mgorny Tags: #clang Differential Revision: https://reviews.llvm.org/D69922
OpenPOWER on IntegriCloud