summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains
Commit message (Collapse)AuthorAgeFilesLines
...
* [PowerPC] Default to -fomit-frame-pointer when optimization is enabledFangrui Song2019-07-121-3/+3
| | | | | | | NetBSD, Linux, CloudABI and Hurd already omit frame pointer for PowerPC. Make it do so for other platforms. llvm-svn: 365862
* [Driver] Refactor interaction between -f(no-)?omit-frame-pointer and ↵Fangrui Song2019-07-121-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -m(no-)?omit-leaf-frame-pointer Use a tri-state enum to represent shouldUseFramePointer() and shouldUseLeafFramePointer(). This simplifies the logic and fixes PR9825: -fno-omit-frame-pointer doesn't imply -mno-omit-leaf-frame-pointer. and PR24003: /Oy- /O2 should not omit leaf frame pointer: this matches MSVC x86-32. (/Oy- is a no-op on MSVC x86-64.) and: when CC1 option -mdisable-fp-elim if absent, -momit-leaf-frame-pointer can also be omitted. The new behavior matches GCC: -fomit-frame-pointer wins over -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer loses out to -momit-leaf-frame-pointer The behavior makes lots of sense. We have 4 states: - 00) leaf retained, non-leaf retained - 01) leaf retained, non-leaf omitted (this is invalid) - 10) leaf omitted, non-leaf retained (what -momit-leaf-frame-pointer was designed for) - 11) leaf omitted, non-leaf omitted "omit" options taking precedence over "no-omit" options is the only way to make 3 valid states representable with -f(no-)?omit-frame-pointer and -m(no-)?omit-leaf-pointer. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D64294 llvm-svn: 365860
* driver: Don't warn about assembler flags being unused when not assemblingNico Weber2019-07-101-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | clang currently warns when passing flags for the assembler (e.g. -Wa,-mbig-obj) to an invocation that doesn't run the assembler (e.g. -E). At first sight, that makes sense -- the flag really is unused. But many other flags don't have an effect if no assembler runs (e.g. -fno-integrated-as, -ffunction-sections, and many others), and those currently don't warn. So this seems more like a side effect of how CollectArgsForIntegratedAssembler() is implemented than like an intentional feature. Since it's a bit inconvenient when debugging builds and adding -E, always call CollectArgsForIntegratedAssembler() to make sure assembler args always get claimed. Currently, this affects only these flags: -mincremental-linker-compatible, -mimplicit-it= (on ARM), -Wa, -Xassembler It does have the side effect that assembler options now need to be valid even if -E is passed. Previously, `-Wa,-mbig-obj` would error for non-coff output only if the assembler ran, now it always errors. This too makes assembler flags more consistent with all the other flags and seems like a progression. Fixes PR42066. Differential Revision: https://reviews.llvm.org/D64527 llvm-svn: 365703
* Update libc++ include path detection to use VFS on LinuxJulie Hockett2019-07-101-6/+7
| | | | | | | | | | The DetectLibcxxIncludePath function had been using llvm::sys::fs::directory_iterator, and this updates it to use llvm::vfs::directory_iterator. Differential Revision: https://reviews.llvm.org/D64381 llvm-svn: 365682
* [X86][PPC] Support -mlong-double-64Fangrui Song2019-07-091-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | -mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}). On many other targets, there will be an error: error: unrecognized command line option '-mlong-double-64' This patch makes the driver option -mlong-double-64 available for x86 and ppc. The CC1 option -mlong-double-64 is available on all targets for users to test on unsupported targets. LongDoubleSize is added as a VALUE_LANGOPT so that the option can be shared with -mlong-double-128 when we support it in clang. Also, make powerpc*-linux-musl default to use 64-bit long double. It is currently the only supported ABI on musl and is also how people configure powerpc*-linux-musl-gcc. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64067 llvm-svn: 365412
* [Sanitizers] Don't use clang_rt.sancov_{begin,end} on SolarisRainer Orth2019-07-081-14/+0
| | | | | | | | | | | | | As explained in https://reviews.llvm.org/D63601, there's no point using clang_rt.sancov_{begin,end} on Solaris any longer. This companion patch to the above removes their use from the driver. Tested on amd64-pc-solaris2.11 Differential Revision: https://reviews.llvm.org/D63602 llvm-svn: 365396
* [RISCV][NFC] Make use of Triple::isRISCVAlex Bradbury2019-07-082-7/+2
| | | | | | Use new helper introduced in rL365327. llvm-svn: 365329
* [clang][Driver][ARM] NFC: Remove unused function parameterAlexandros Lamprineas2019-07-021-7/+5
| | | | | | | | | Removes a vector reference that was added by D62998, since the preexisting function parameter is sufficient. Differential Revision: https://reviews.llvm.org/D64044 llvm-svn: 364895
* [RISCV] Avoid save-restore target feature warningSam Elliott2019-07-011-5/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: LLVM issues a warning if passed unknown target features. Neither I nor @asb noticed this until after https://reviews.llvm.org/D63498 landed. This patch stops passing the (unknown) "save-restore" target feature to the LLVM backend, but continues to emit a warning if a driver asks for `-msave-restore`. The default of assuming `-mno-save-restore` (and emitting no warnings) remains. Reviewers: asb Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, cfe-commits, asb Tags: #clang Differential Revision: https://reviews.llvm.org/D64008 llvm-svn: 364777
* Revert enabling frame pointer elimination on OpenBSD for now.Brad Smith2019-06-281-13/+0
| | | | llvm-svn: 364679
* [Hexagon] driver uses out-of-date option name and binary nameKrzysztof Parzyszek2019-06-281-2/+2
| | | | | | | | Patch by A. Skrobov (t.yomitch). Differential Revision: https://reviews.llvm.org/D62127 llvm-svn: 364648
* [Clang] Remove unused -split-dwarf and obsolete -enable-split-dwarfAaron Puchert2019-06-261-12/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: The changes in D59673 made the choice redundant, since we can achieve single-file split DWARF just by not setting an output file name. Like llc we can also derive whether to enable Split DWARF from whether -split-dwarf-file is set, so we don't need the flag at all anymore. The test CodeGen/split-debug-filename.c distinguished between having set or not set -enable-split-dwarf with -split-dwarf-file, but we can probably just always emit the metadata into the IR. The flag -split-dwarf wasn't used at all anymore. Reviewers: dblaikie, echristo Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D63167 llvm-svn: 364479
* [WebAssembly] Implement Address Sanitizer for EmscriptenGuanzhong Chen2019-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This diff enables address sanitizer on Emscripten. On Emscripten, real memory starts at the value passed to --global-base. All memory before this is used as shadow memory, and thus the shadow mapping function is simply dividing by 8. Reviewers: tlively, aheejin, sbc100 Reviewed By: sbc100 Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63742 llvm-svn: 364468
* Make AddLastArg() variadic and use it more. No behavior change.Nico Weber2019-06-261-27/+15
| | | | llvm-svn: 364453
* [HIP] Support attribute hip_pinned_shadowYaxun Liu2019-06-261-3/+2
| | | | | | | | | | | | | | | This patch introduces support of hip_pinned_shadow variable for HIP. A hip_pinned_shadow variable is a global variable with attribute hip_pinned_shadow. It has external linkage on device side and has no initializer. It has internal linkage on host side and has initializer or static constructor. It can be accessed in both device code and host code. This allows HIP runtime to implement support of HIP texture reference. Differential Revision: https://reviews.llvm.org/D62738 llvm-svn: 364381
* android: enable double-word CAS on x64Saleem Abdulrasool2019-06-251-0/+1
| | | | | | | | | | | The android target assumes that for the x86_64 target, the CPU supports SSE4.2 and popcnt. This implies that the CPU is Nehalem or newer. This should be sufficiently new to provide the double word compare and exchange instruction. This allows us to directly lower `__sync_val_compare_and_swap_16` to a `cmpxchg16b`. It appears that the libatomic in android's NDK does not provide the implementation for lowering calls to the library function. llvm-svn: 364352
* [RISC-V] Add -msave-restore and -mno-save-restore to clang driverSam Elliott2019-06-211-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The GCC RISC-V toolchain accepts `-msave-restore` and `-mno-save-restore` to control whether libcalls are used for saving and restoring the stack within prologues and epilogues. Clang currently errors if someone passes -msave-restore or -mno-save-restore. This means that people need to change build configurations to use clang. This patch adds these flags, so that clang invocations can now match gcc. As the RISC-V backend does not currently have a `save-restore` target feature, we emit a warning if someone requests `-msave-restore`. LLVM does not error if we pass the (unimplemented) target features `+save-restore` or `-save-restore`. Reviewers: asb, luismarques Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63498 llvm-svn: 364018
* [clang-ifs] Clang Interface Stubs, first version (second landing attempt).Puyan Lotfi2019-06-201-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change reverts r363649; effectively re-landing r363626. At this point clang::Index::CodegenNameGeneratorImpl has been refactored into clang::AST::ASTNameGenerator. This makes it so that the previous circular link dependency no longer exists, fixing the previous share lib (-DBUILD_SHARED_LIBS=ON) build issue which was the reason for r363649. Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Currently clang-ifs produces .ifs files that can be thought of as analogous to object (.o) files, but just for the mangled symbol info. In a subsequent patch I intend to add support for merging the .ifs files into one .ifs/.ifso file that can be the input to something like llvm-elfabi to produce something like a .so file or .dll (but without any of the code, just symbols). Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363948
* AMDGPU: Disable errno by defaultMatt Arsenault2019-06-181-0/+2
| | | | llvm-svn: 363682
* Revert D60974 "[clang-ifs] Clang Interface Stubs, first version."Fangrui Song2019-06-181-19/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit rC363626. clangIndex depends on clangFrontend. r363626 adds a dependency from clangFrontend to clangIndex, which creates a circular dependency. This is disallowed by -DBUILD_SHARED_LIBS=on builds: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): "clangFrontend" of type SHARED_LIBRARY depends on "clangIndex" (weak) "clangIndex" of type SHARED_LIBRARY depends on "clangFrontend" (weak) At least one of these targets is not a STATIC_LIBRARY. Cyclic dependencies are allowed only among static libraries. Note, the dependency on clangIndex cannot be removed because libclangFrontend.so is linked with -Wl,-z,defs: a shared object must have its full direct dependencies specified on the linker command line. In -DBUILD_SHARED_LIBS=off builds, this appears to work when linking `bin/clang-9`. However, it can cause trouble to downstream clang library users. The llvm build system links libraries this way: clang main_program_object_file ... lib/libclangIndex.a ... lib/libclangFrontend.a -o exe libclangIndex.a etc are not wrapped in --start-group. If the downstream application depends on libclangFrontend.a but not any other clang libraries that depend on libclangIndex.a, this can cause undefined reference errors when the linker is ld.bfd or gold. The proper fix is to not include clangIndex files in clangFrontend. llvm-svn: 363649
* [Remarks][Driver] Use the specified format in the remarks file extensionFrancis Visoiu Mistrih2019-06-172-2/+16
| | | | | | | By default, use `.opt.yaml`, but when a format is specified with `-fsave-optimization-record=<format>`, use `.opt.<format>`. llvm-svn: 363627
* [clang-ifs] Clang Interface Stubs, first version.Puyan Lotfi2019-06-171-0/+19
| | | | | | | | | | | | | | | | | | | Clang interface stubs (previously referred to as clang-ifsos) is a new frontend action in clang that allows the generation of stub files that contain mangled name info that can be used to produce a stub library. These stub libraries can be useful for breaking up build dependencies and controlling access to a library's internal symbols. Generation of these stubs can be invoked by: clang -fvisibility=<visibility> -emit-interface-stubs \ -interface-stub-version=<interface format> Notice that -fvisibility (along with use of visibility attributes) can be used to control what symbols get generated. Currently the interface format is experimental but there are a wide range of possibilities here. Differential Revision: https://reviews.llvm.org/D60974 llvm-svn: 363626
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-172-0/+17
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* Promote -fdebug-compilation-dir from a cc1 flag to clang and clang-cl driver ↵Nico Weber2019-06-171-2/+7
| | | | | | | | | | | | | | | | | | | | | flags The flag is useful when wanting to create .o files that are independent from the absolute path to the build directory. -fdebug-prefix-map= can be used to the same effect, but it requires putting the absolute path to the build directory on the build command line, so it still requires the build command line to be dependent on the absolute path of the build directory. With this flag, "-fdebug-compilation-dir ." makes it so that both debug info and the compile command itself are independent of the absolute path of the build directory, which is good for build determinism (in the sense that the build is independent of which directory it happens in) and for caching compile results. (The tradeoff is that the debugger needs explicit configuration to know the build directory. See also http://dwarfstd.org/ShowIssue.php?issue=171130.2) Differential Revision: https://reviews.llvm.org/D63387 llvm-svn: 363548
* [Clang] Harmonize Split DWARF options with llcAaron Puchert2019-06-151-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With Split DWARF the resulting object file (then called skeleton CU) contains the file name of another ("DWO") file with the debug info. This can be a problem for remote compilation, as it will contain the name of the file on the compilation server, not on the client. To use Split DWARF with remote compilation, one needs to either * make sure only relative paths are used, and mirror the build directory structure of the client on the server, * inject the desired file name on the client directly. Since llc already supports the latter solution, we're just copying that over. We allow setting the actual output filename separately from the value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU. Fixes PR40276. Reviewers: dblaikie, echristo, tejohnson Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D59673 llvm-svn: 363496
* [Clang] Rename -split-dwarf-file to -split-dwarf-outputAaron Puchert2019-06-151-2/+2
| | | | | | | | | | | | | | | | | | Summary: This is the first in a series of changes trying to align clang -cc1 flags for Split DWARF with those of llc. The unfortunate side effect of having -split-dwarf-output for single file Split DWARF will disappear again in a subsequent change. The change is the result of a discussion in D59673. Reviewers: dblaikie, echristo Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D63130 llvm-svn: 363494
* [AMDGPU] gfx1010 wave32 clang supportStanislav Mekhanoshin2019-06-132-2/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D63209 llvm-svn: 363341
* [WebAssembly] Modernize include path handlingSam Clegg2019-06-131-7/+34
| | | | | | | | | | Move include path construction from InitHeaderSearch::AddDefaultIncludePaths in the Driver which appears to be the more modern/correct way of doing things. Differential Revision: https://reviews.llvm.org/D63030 llvm-svn: 363241
* Revert r344630 Disable code object version 3 for HIP toolchain.Yaxun Liu2019-06-111-1/+1
| | | | | | Remove the workaround so that by default code object v3 is enabled. llvm-svn: 363076
* Driver, IRGen: Set partitions on GlobalValues according to ↵Peter Collingbourne2019-06-071-0/+8
| | | | | | | | -fsymbol-partition flag. Differential Revision: https://reviews.llvm.org/D62636 llvm-svn: 362829
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-16/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
* [WebAssembly] Support Leak Sanitizer on EmscriptenThomas Lively2019-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: LSan is currently being ported to Emscripten and mostly works. Enabling the support in upstream would simplify testing. Patch by Guanzhong Chen. Reviewers: tlively, aheejin Reviewed By: aheejin Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62830 llvm-svn: 362667
* [ARM] Allow "-march=foo+fp" to vary with fooSjoerd Meijer2019-06-052-29/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now, when clang processes an argument of the form "-march=foo+x+y+z", then instead of calling getArchExtFeature() for each of the extension names "x", "y", "z" and appending the returned string to its list of low-level subtarget features, it will call appendArchExtFeatures() which does the appending itself. The difference is that appendArchExtFeatures can add _more_ than one low-level feature name to the output feature list if it has to, and also, it gets told some information about what base architecture and CPU the extension is going to go with, which means that "+fp" can now mean something different for different CPUs. Namely, "+fp" now selects whatever the _default_ FPU is for the selected CPU and/or architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in ARMTargetParser.def. On the clang side, I adjust DecodeARMFeatures to call the new appendArchExtFeatures function in place of getArchExtFeature. This means DecodeARMFeatures needs to be passed a CPU name and an ArchKind, which meant changing its call sites to make those available, and also sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind enum value out of it instead of a string. Also, I add support here for the extension name "+fp.dp", which will automatically look through the FPU list for something that looks just like the default FPU except for also supporting double precision. Differential Revision: https://reviews.llvm.org/D60697 llvm-svn: 362601
* [ARM] Fix recent breakage of -mfpu=none.Simon Tatham2019-06-031-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent change D60691 introduced a bug in clang when handling option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those options together should select Cortex-M4 but disable all use of hardware FP, but in fact, now hardware FP instructions can still be generated in that mode. The reason is because the handling of FPUVersion::NONE disables all the same feature names it used to, of which the base one is `vfp2`. But now there are further features below that, like `vfp2d16fp` and (following D60694) `fpregs`, which also need to be turned off to disable hardware FP completely. Added a tiny test which double-checks that compiling a simple FP function doesn't access the FP registers. Reviewers: SjoerdMeijer, dmgreen Reviewed By: dmgreen Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62729 llvm-svn: 362380
* [Driver] Render target options (e.g. -fuse-init-array) for -fembed-bitcodeFangrui Song2019-05-301-0/+3
| | | | | | | | | | | | | | | | | | | | | Modern ELF platforms use -fuse-init-array to emit .init_array instead of .ctors . ld.bfd and gold --ctors-in-init-array merge .init_array and .ctors into .init_array but lld doesn't do that. If crtbegin*.o crtend*.o don't provide .ctors/.dtors, such .ctors in user object files can lead to crash (see PR42002. The first and the last elements in .ctors/.dtors are ignored - they are traditionally provided by crtbegin*.o crtend*.o). Call addClangTargetOptions() to ensure -fuse-init-array is rendered on modern ELF platforms. On Hexagon, this renders -target-feature +reserved-r19 for -ffixed-r19. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D62509 llvm-svn: 362052
* [PowerPC] Set the default PLT mode on musl to Secure PLTFangrui Song2019-05-301-1/+1
| | | | | | | | | | | | The musl libc only supports Secure PLT. Patch by A. Wilcox! Reviewed By: jhibbits Differential Revision: https://reviews.llvm.org/D59185 llvm-svn: 362051
* [Driver] -static-pie: add -z textFangrui Song2019-05-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This matches gcc -static-pie. The intention is to prevent dynamic relocations in read-only segments. In ld.bfd and gold, -z notext is the default. If text relocations are needed: * -z notext: allow and emit DF_TEXTREL. DF_TEXTREL is not emitted if there is no text relocation. * -z text: error In lld, -z text is the default (this change is a no-op). * -z text: error on text relocations * -z notext: allow text relocations, and emit DF_TEXTREL no matter whether text relocations exist. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D62606 llvm-svn: 362050
* [WebAssembly] Support VPtr sanitizer for EmscriptenThomas Lively2019-05-292-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Summary: After https://github.com/emscripten-core/emscripten/pull/8651, Emscripten supports the full UBSan runtime. This includes the VPtr sanitizer. This diff allows clang to generate code that uses the VPtr sanitizer for Emscripten. Patch by Guanzhong Chen Reviewers: tlively, aheejin Reviewed By: aheejin Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62559 llvm-svn: 362004
* [Driver] Fix -working-directory issuesMichael J. Spencer2019-05-281-13/+8
| | | | | | | | | | | | | | | | Currently the `-working-directory` option does not actually impact the working directory for all of the clang driver, it only impacts how files are looked up to make sure they exist. This means that that clang passes the wrong paths to -fdebug-compilation-dir and -coverage-notes-file. This patch fixes that by changing all the places in the driver where we convert to absolute paths to use the VFS, and then calling setCurrentWorkingDirectory on the VFS. This also changes the default VFS for `Driver` to use a virtualized working directory, instead of changing the process's working directory. Differential Revision: https://reviews.llvm.org/D62271 llvm-svn: 361885
* [Driver][RISCV] Simplify. NFCFangrui Song2019-05-261-31/+13
| | | | llvm-svn: 361710
* [Driver] Update handling of c++ and runtime directoriesPetr Hosek2019-05-261-19/+14
| | | | | | | | | | | | This is a follow up to r361432 and r361504 which addresses issues introduced by those changes. Specifically, it avoids duplicating file and runtime paths in case when the effective triple is the same as the cannonical one. Furthermore, it fixes the broken multilib setup in the Fuchsia driver and deduplicates some of the code. Differential Revision: https://reviews.llvm.org/D62442 llvm-svn: 361709
* [WebAssembly] Use "linker" as linker shortname.Sam Clegg2019-05-242-10/+4
| | | | | | | | | | | This is in line with other platforms. Also, move the single statement methods into the header (also in line with other platform). Differential Revision: https://reviews.llvm.org/D62406 llvm-svn: 361651
* [Driver] Move the "-o OUT -x TYPE SRC.c" flags to the end of -cc1Reid Kleckner2019-05-231-24/+26
| | | | | | | | | | | New -cc1 arguments, such as -faddrsig, have started appearing after the input name. I personally find it convenient for the input to be the last argument to the compile command line, since I often need to edit it when running crash reproduction scripts. Differential Revision: https://reviews.llvm.org/D62270 llvm-svn: 361530
* [runtimes] Move libunwind, libc++abi and libc++ to lib/$target/c++ and ↵Petr Hosek2019-05-222-3/+2
| | | | | | | | | | | | | | | | | include/c++ This change is a consequence of the discussion in "RFC: Place libs in Clang-dedicated directories", specifically the suggestion that libunwind, libc++abi and libc++ shouldn't be using Clang resource directory. Tools like clangd make this assumption, but this is currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build. This change addresses that by moving the output of these libraries to lib/$target/c++ and include/c++ directories, leaving resource directory only for compiler-rt runtimes and Clang builtin headers. Differential Revision: https://reviews.llvm.org/D59168 llvm-svn: 361432
* Add back --sysroot support for darwin header search.James Y Knight2019-05-222-9/+14
| | | | | | | | | | | | | | | | Before e97b5f5cf37e ([clang][Darwin] Refactor header search path logic into the driver), both --sysroot and -isysroot worked to specify where to look for system and C++ headers on Darwin. However, that change caused clang to start ignoring --sysroot. This fixes the regression, and adds tests. (I also note that on all other platforms, clang seems to almost completely ignore -isysroot, but that's another issue...) Differential Revision: https://reviews.llvm.org/D62268 llvm-svn: 361429
* [Driver][Windows] Add dependent lib argument for -fprofile-generate and ↵Russell Gallop2019-05-221-0/+4
| | | | | | | | | | -fcs-profile-generate Follows on from r360674 which added it for -fprofile-instr-generate. Differential Revision: https://reviews.llvm.org/D62200 llvm-svn: 361368
* [Driver] Verify GCCInstallation is validNick Desaulniers2019-05-211-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Values returned by GCCInstallation.getParentLibPath() and GCCInstallation.getTriple() are not valid unless GCCInstallation.isValid() returns true. This has previously been ignored, and the former two values were used without checking whether GCCInstallation is valid. This led to the bad path "/../bin" being added to the list of program paths. author: danielmentz "Daniel Mentz <danielmentz@google.com>" Reviewers: #clang, tstellar, srhines Reviewed By: srhines Subscribers: danielmentz, ormris, nickdesaulniers, srhines, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57930 llvm-svn: 361314
* Let -static-pie win if it is specified along with -pie or -static.Siva Chandra2019-05-211-7/+28
| | | | | | | | Also, disallow specifying -no-pie/-nopie along with -static-pie. Differential Revision: https://reviews.llvm.org/D59841 llvm-svn: 361312
* [clang][Darwin] Refactor header search path logic into the driverLouis Dionne2019-05-212-12/+167
| | | | | | | | | | | | | | | | | | | | | | | Summary: This commit moves the logic for determining system, resource and C++ header search paths from CC1 to the driver. This refactor has already been made for several platforms, but Darwin had been left behind. This refactor tries to implement the previous search path logic with perfect accuracy. In particular, the order of all include paths inside CC1 and all paths that were skipped because nonexistent are conserved after the refactor. This change was also tested against a code base of significant size and revealed no problems. Reviewers: jfb, arphaman Subscribers: nemanjai, javed.absar, kbarton, christof, jkorous, dexonsmith, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61963 llvm-svn: 361278
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-212-0/+7
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
OpenPOWER on IntegriCloud