summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
...
* [Driver] Simplify -lgcc & -lgcc_sFangrui Song2019-07-141-17/+13
| | | | | | | gcc defaults to -shared-libgcc in C++ mode. Letting getLibGccType() return SharedLibGcc simplifies the logic. llvm-svn: 366012
* [CMake][Fuchsia] Define asan+noexcept multilibPetr Hosek2019-07-131-0/+5
| | | | | | | | | | | | | | | | | | Using noexcept multilib with -fno-exceptions can lead to significant space savings when statically linking libc++abi because we don't need all the unwinding and demangling code. When compiling with ASan, we already get a lot of overhead from the instrumentation itself, when statically linking libc++abi, that overhead is even larger. Having the noexcept variant for ASan can help significantly, we've seen more than 50% size reduction in our system image, which offsets the cost of having to build another multilib. Differential Revision: https://reviews.llvm.org/D64140 llvm-svn: 365994
* Revert driver: Don't warn about assembler flags being unused when not assemblingReid Kleckner2019-07-121-12/+0
| | | | | | | | | | | This reverts r365703 (git commit 101c1afdfd1c88f05da94c6fd317b489bb704f40) and r365714. This broke some autoconf-style assembler flags checks in the Linux build: https://github.com/ClangBuiltLinux/linux/issues/598 llvm-svn: 365956
* [WebAssembly] Make pthread imply bulk-memory, mutable-globalsThomas Lively2019-07-121-1/+15
| | | | | | | | | | | | | | | | | Summary: This paves the way for using passive segments in pthread builds, which will make separate memory files unnecessary. Mutable globals are also necessary for the upcoming implementation of TLS. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64586 llvm-svn: 365935
* [Driver] Delete dead codeFangrui Song2019-07-122-7/+1
| | | | llvm-svn: 365898
* [Driver] Delete --no-add-needed for RHEL7 or newerFangrui Song2019-07-121-3/+0
| | | | | | | | This is really not needed. gcc driver doesn't add this option. BTW, since binutils 2.22, --no-copy-dt-needed-entries (new name of --no-add-needed) is the default. llvm-svn: 365877
* [X86][PowerPC] Support -mlong-double-128Fangrui Song2019-07-121-5/+5
| | | | | | | | | | | | | | | This patch makes the driver option -mlong-double-128 available for X86 and PowerPC. The CC1 option -mlong-double-128 is available on all targets for users to test on unsupported targets. On PowerPC, -mlong-double-128 uses the IBM extended double format because we don't support -mabi=ieeelongdouble yet (D64283). Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64277 llvm-svn: 365866
* [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] -noprofilelib flagPetr Hosek2019-07-111-0/+3
| | | | | | | | | | This flag is analoguous to other flags like -nostdlib or -nolibc and could be used to disable linking of profile runtime library. This is useful in certain environments like kernel, where profile instrumentation is still desirable, but we cannot use the standard runtime library. llvm-svn: 365808
* 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
* [Driver] Add float-divide-by-zero back to supported sanitizers after ↵Fangrui Song2019-07-102-7/+10
| | | | | | | | | | | | | | | | | | D63793/rC365272 D63793 removed float-divide-by-zero from the "undefined" set but it failed to add it to getSupportedSanitizers(), thus the sanitizer is rejected by the driver: clang-9: error: unsupported option '-fsanitize=float-divide-by-zero' for target 'x86_64-unknown-linux-gnu' Also, add SanitizerMask::FloatDivideByZero to a few other masks to make -fsanitize-trap, -fsanitize-recover, -fsanitize-minimal-runtime and -fsanitize-coverage work. Reviewed By: rsmith, vitalybuka Differential Revision: https://reviews.llvm.org/D64317 llvm-svn: 365587
* [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
* Add a comment explaining why a function existsNico Weber2019-07-051-0/+3
| | | | llvm-svn: 365212
* Make joined instances of JoinedOrSeparate flags point to the unaliased args, ↵Nico Weber2019-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | like all other arg types do This fixes an 8-year-old regression. r105763 made it so that aliases always refer to the unaliased option – but it missed the "joined" branch of JoinedOrSeparate flags. (r162231 then made the Args classes non-virtual, and r169344 moved them from clang to llvm.) Back then, there was no JoinedOrSeparate flag that was an alias, so it wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias in clang, and warn_slash_u_filename incorrectly used the aliased arg id (using the unaliased one isn't really a regression since that warning checks if the undefined macro contains slash or backslash and only then emits the warning – and no valid use will pass "-Ufoo/bar" or similar). Also, lld has many JoinedOrSeparate aliases, and due to this bug it had to explicitly call `getUnaliasedOption()` in a bunch of places, even though that shouldn't be necessary by design. After this fix in Option, these calls really don't have an effect any more, so remove them. No intended behavior change. (I accidentally fixed this bug while working on PR29106 but then wondered why the warn_slash_u_filename broke. When I figured it out, I thought it would make sense to land this in a separate commit.) Differential Revision: https://reviews.llvm.org/D64156 llvm-svn: 365186
* [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
* [Driver] Fix style issues of --print-supported-cpus after D63105Fangrui Song2019-06-291-12/+8
| | | | | | | | Reviewed By: ziangwan Differential Revision: https://reviews.llvm.org/D63822 llvm-svn: 364704
* 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
* print-supported-cpus quality of life patch.Ziang Wan2019-06-251-3/+9
| | | | | | | Claim all input files so that clang does not give a warning. Add two short-cut aliases: -mcpu=? and -mtune=?. llvm-svn: 364362
* 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-202-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-182-22/+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-172-0/+22
| | | | | | | | | | | | | | | | | | | 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
* Add --print-supported-cpus flag for clang.Ziang Wan2019-06-141-1/+13
| | | | | | | | | | | | This patch allows clang users to print out a list of supported CPU models using clang [--target=<target triple>] --print-supported-cpus Then, users can select the CPU model to compile to using clang --target=<triple> -mcpu=<model> a.c It is a handy feature to help cross compilation. llvm-svn: 363464
* AMDGPU: Use AMDGPU toolchain for other OSesMatt Arsenault2019-06-141-0/+2
| | | | | | | This would need more work to actually support them, but this is less wrong than the default. llvm-svn: 363390
* [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
* Fix compilation warning about unused variable [NFC]Mikael Holmen2019-06-031-1/+1
| | | | llvm-svn: 362379
OpenPOWER on IntegriCloud