summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend/CompilerInvocation.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to ↵Calixte Denizet2018-11-171-0/+4
| | | | | | | | | | | | | | | | | | filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659) Summary: the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows. So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c. Reviewers: marco-c Reviewed By: marco-c Subscribers: cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D54600 llvm-svn: 347144
* Sink BuryPointer from Clang into LLVM for reuse thereDavid Blaikie2018-11-171-15/+0
| | | | llvm-svn: 347141
* [codeview] Expose -gcodeview-ghash for global type hashingReid Kleckner2018-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Experience has shown that the functionality is useful. It makes linking optimized clang with debug info for me a lot faster, 20s to 13s. The type merging phase of PDB writing goes from 10s to 3s. This removes the LLVM cl::opt and replaces it with a metadata flag. After this change, users can do the following to use ghash: - add -gcodeview-ghash to compiler flags - replace /DEBUG with /DEBUG:GHASH in linker flags Reviewers: zturner, hans, thakis, takuto.ikuta Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D54370 llvm-svn: 347072
* [c++20] Implement P0482R6: enable -fchar8_t by default in C++20 mode.Richard Smith2018-11-141-1/+1
| | | | | | | | | | | | | This unfortunately results in a substantial breaking change when switching to C++20, but it's not yet clear what / how much we should do about that. We may want to add a compatibility conversion from u8 string literals to const char*, similar to how C++98 provided a compatibility conversion from string literals to non-const char*, but that's not handled by this patch. The feature can be disabled in C++20 mode with -fno-char8_t. llvm-svn: 346892
* [Clang] - Add '-gsplit-dwarf[=split,=single]' version for '-gsplit-dwarf' ↵George Rimar2018-11-141-1/+17
| | | | | | | | | | | | | | | | | | | | option. The DWARF5 specification says(Appendix F.1): "The sections that do not require relocation, however, can be written to the relocatable object (.o) file but ignored by the linker or they can be written to a separate DWARF object (.dwo) file that need not be accessed by the linker." The first part describes a single file split DWARF feature and there is no way to trigger this behavior atm. Fortunately, no many changes are required to keep *.dwo sections in a .o, the patch does that. Differential revision: https://reviews.llvm.org/D52296 llvm-svn: 346837
* DebugInfo: Add a driver flag for DWARF debug_ranges base address specifier use.David Blaikie2018-11-131-0/+1
| | | | | | | | | | | | | | | Summary: This saves a lot of relocations in optimized object files (at the cost of some cost/increase in linked executable bytes), but gold's 32 bit gdb-index support has a bug ( https://sourceware.org/bugzilla/show_bug.cgi?id=21894 ) so we can't switch to this unconditionally. (& even if it weren't for that bug, one might argue that some users would want to optimize in one direction or the other - prioritizing object size or linked executable size) Differential Revision: https://reviews.llvm.org/D54243 llvm-svn: 346789
* Revert rL346644, rL346642: the added test ↵Calixte Denizet2018-11-121-4/+0
| | | | | | test/CodeGen/code-coverage-filter.c is failing under windows llvm-svn: 346659
* [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to ↵Calixte Denizet2018-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | filter the files to instrument with gcov Summary: These options are taking regex separated by colons to filter files. - if both are empty then all files are instrumented - if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented - if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented - if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented - this patch is a follow-up of https://reviews.llvm.org/D52033 Reviewers: marco-c, vsk Reviewed By: marco-c, vsk Subscribers: cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D52034 llvm-svn: 346642
* Add /Zc:DllexportInlines option to clang-clTakuto Ikuta2018-11-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This CL adds /Zc:DllexportInlines flag to clang-cl. When Zc:DllexportInlines- is specified, inline class member function is not exported if the function does not have local static variables. By not exporting inline function, code for those functions are not generated and that reduces both compile time and obj size. Also this flag does not import inline functions from dllimported class if the function does not have local static variables. On my 24C48T windows10 machine, build performance of chrome target in chromium repository is like below. These stats are come with 'target_cpu="x86" enable_nacl = false is_component_build=true dcheck_always_on=true` build config and applied * https://chromium-review.googlesource.com/c/chromium/src/+/1212379 * https://chromium-review.googlesource.com/c/v8/v8/+/1186017 Below stats were taken with this patch applied on https://github.com/llvm-project/llvm-project-20170507/commit/a05115cd4c57ff76b0f529e38118765b58ed7f2e | config | build time | speedup | build dir size | | with patch, PCH on, debug | 1h10m0s | x1.13 | 35.6GB | | without patch, PCH on, debug | 1h19m17s | | 49.0GB | | with patch, PCH off, debug | 1h15m45s | x1.16 | 33.7GB | | without patch, PCH off, debug | 1h28m10s | | 52.3GB | | with patch, PCH on, release | 1h13m13s | x1.22 | 26.2GB | | without patch, PCH on, release | 1h29m57s | | 37.5GB | | with patch, PCH off, release | 1h23m38s | x1.32 | 23.7GB | | without patch, PCH off, release | 1h50m50s | | 38.7GB | This patch reduced obj size and the number of exported symbols largely, that improved link time too. e.g. link time stats of blink_core.dll become like below | | cold disk cache | warm disk cache | | with patch, PCH on, debug | 71s | 30s | | without patch, PCH on, debug | 111s | 48s | This patch's implementation is based on Nico Weber's patch. I modified to support static local variable, added tests and took stats. Bug: https://bugs.llvm.org/show_bug.cgi?id=33628 Reviewers: hans, thakis, rnk, javed.absar Reviewed By: hans Subscribers: kristof.beyls, smeenai, dschuff, probinson, cfe-commits, eraman Differential Revision: https://reviews.llvm.org/D51340 llvm-svn: 346069
* Change -fsanitize-address-poison-class-member-array-new-cookie to ↵Filipe Cabecinhas2018-11-021-4/+4
| | | | | | | | | | | | | | -fsanitize-address-poison-custom-array-cookie Handle it in the driver and propagate it to cc1 Reviewers: rjmccall, kcc, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52615 llvm-svn: 346001
* [analyzer] New flag to print all -analyzer-config optionsKristof Umann2018-11-021-0/+1
| | | | | | | | A new -cc1 flag is avaible for the said purpose: -analyzer-config-help Differential Revision: https://reviews.llvm.org/D53296 llvm-svn: 345989
* [OPENMP][NVPTX]Improve emission of the globalized variables forAlexey Bataev2018-11-021-0/+8
| | | | | | | | | | | | | | | | | | | target/teams/distribute regions. Target/teams/distribute regions exist for all the time the kernel is executed. Thus, if the variable is declared in their context and then escape it, we can allocate global memory statically instead of allocating it dynamically. Patch captures all the globalized variables in target/teams/distribute contexts, merges them into the records, one per each target region. Those records are then joined into the union, one per compilation unit (to save the global memory). Those units are organized into 2 x dimensional arrays, where the first dimension is the number of blocks per SM and the second one is the number of SMs. Runtime functions manage this global memory space between the executing teams. llvm-svn: 345978
* Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2018-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-2/+2
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* [VFS] Add property 'fallthrough' that controls fallback to real file system.Volodymyr Sapsai2018-10-261-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Default property value 'true' preserves current behavior. Value 'false' can be used to create VFS "root", file system that gives better control over which files compiler can use during compilation as there are no unpredictable accesses to real file system. Non-fallthrough use case changes how we treat multiple VFS overlay files. Instead of all of them being at the same level just above a real file system, now they are nested and subsequent overlays can refer to files in previous overlays. Change is done both in LLVM and Clang, corresponding LLVM commit is r345431. rdar://problem/39465552 Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits, hiraditya Differential Revision: https://reviews.llvm.org/D50539 llvm-svn: 345432
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-0/+2
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* [AArch64] Branch Protection and Return Address Signing B Key SupportLuke Cheeseman2018-10-251-2/+20
| | | | | | | | | | | - Add support for -mbranch-protection=<type>[+<type>]* where - <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*] - The protection emits relevant function attributes - sign-return-address=<scope> - sign-return-address-key=<key> - branch-protection llvm-svn: 345273
* Driver,CodeGen: introduce support for Swift CFString layoutSaleem Abdulrasool2018-10-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new driver level flag `-fcf-runtime-abi=` that allows one to specify the runtime ABI for CoreFoundation. This controls the language interoperability. In particular, this is relevant for generating the CFConstantString classes (primarily through the `__builtin___CFStringMakeConstantString` builtin) which construct a reference to the "CFObject"'s `isa` field. This type differs between swift 4.1 and 4.2+. Valid values for the new option include: - objc [default behaviour] - enable ObjectiveC interoperability - swift-4.1 - enable interoperability with swift 4.1 - swift-4.2 - enable interoperability with swift 4.2 - swift-5.0 - enable interoperability with swift 5.0 - swift [alias] - target the latest swift ABI Furthermore, swift 4.2+ changed the layout for the CFString when building CoreFoundation *without* ObjectiveC interoperability. In such a case, a field was added to the CFObject base type changing it from: <{ const int*, int }> to <{ uintptr_t, uintptr_t, uint64_t }>. In swift 5.0, the CFString type will be further adjusted to change the length from a uint32_t on everything but BE LP64 targets to uint64_t. Note that the default behaviour for clang remains unchanged and the new layout must be explicitly opted into via `-fcf-runtime-abi=swift*`. llvm-svn: 345222
* Add support for -mno-tls-direct-seg-refs to ClangKristina Brooks2018-10-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch exposes functionality added in rL344723 to the Clang driver/frontend as a flag and adds appropriate metadata. Driver tests pass: ``` ninja check-clang-driver -snip- Expected Passes : 472 Expected Failures : 3 Unsupported Tests : 65 ``` Odd failure in CodeGen tests but unrelated to this: ``` ninja check-clang-codegen -snip- /SourceCache/llvm-trunk-8.0/tools/clang/test/CodeGen/builtins-wasm.c:87:10: error: cannot compile this builtin function yet -snip- Failing Tests (1): Clang :: CodeGen/builtins-wasm.c Expected Passes : 1250 Expected Failures : 2 Unsupported Tests : 120 Unexpected Failures: 1 ``` Original commit: [X86] Support for the mno-tls-direct-seg-refs flag Allows to disable direct TLS segment access (%fs or %gs). GCC supports a similar flag, it can be useful in some circumstances, e.g. when a thread context block needs to be updated directly from user space. More info and specific use cases: https://bugs.llvm.org/show_bug.cgi?id=16145 Patch by nruslan (Ruslan Nikolaev). Differential Revision: https://reviews.llvm.org/D53102 llvm-svn: 344739
* Add a flag to remap manglings when reading profile data information.Richard Smith2018-10-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | This can be used to preserve profiling information across codebase changes that have widespread impact on mangled names, but across which most profiling data should still be usable. For example, when switching from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI, or even from a 32-bit to a 64-bit build. The user can provide a remapping file specifying parts of mangled names that should be treated as equivalent (eg, std::__1 should be treated as equivalent to std::__cxx11), and profile data will be treated as applying to a particular function if its name is equivalent to the name of a function in the profile data under the provided equivalences. See the documentation change for a description of how this is configured. Remapping is supported for both sample-based profiling and instruction profiling. We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately. Support is only added for the new pass manager. If someone wants to also add support for this for the old pass manager, doing so should be straightforward. llvm-svn: 344199
* Lift VFS from clang to llvm (NFC)Jonas Devlieghere2018-10-101-10/+10
| | | | | | | | | | | | | | | | | | | This patch moves the virtual file system form clang to llvm so it can be used by more projects. Concretely the patch: - Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support. - Moves the corresponding unit test from clang to llvm. - Moves the vfs namespace from clang::vfs to llvm::vfs. - Formats the lines affected by this change, mostly this is the result of the added llvm namespace. RFC on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html Differential revision: https://reviews.llvm.org/D52783 llvm-svn: 344140
* Introduce code_model macrosAli Tamur2018-10-081-1/+2
| | | | | | | | | | | | | | | | | | | Summary: gcc defines macros such as __code_model_small_ based on the user passed command line flag -mcmodel. clang accepts a flag with the same name and similar effects, but does not generate any macro that the user can use. This cl narrows the gap between gcc and clang behaviour. However, achieving full compatibility with gcc is not trivial: The set of valid values for mcmodel in gcc and clang are not equal. Also, gcc defines different macros for different architectures. In this cl, we only tackle an easy part of the problem and define the macro only for x64 architecture. When the user does not specify a mcmodel, the macro for small code model is produced, as is the case with gcc. Reviewers: compnerd, MaskRay Reviewed By: MaskRay Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D52920 llvm-svn: 344000
* [Frontend] Delete -print-decl-contextsFangrui Song2018-10-031-3/+0
| | | | | | | | | | | | | | Summary: Its job is covered by -ast-dump. The option is rarely used and lacks many AST nodes which will lead to llvm_unreachable() crash. Reviewers: rsmith, arphaman Reviewed By: rsmith Subscribers: jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D52529 llvm-svn: 343660
* [HIP] Support early finalization of device code for -fno-gpu-rdcYaxun Liu2018-10-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This patch renames -f{no-}cuda-rdc to -f{no-}gpu-rdc and keeps the original options as aliases. When -fgpu-rdc is off, clang will assume the device code in each translation unit does not call external functions except those in the device library, therefore it is possible to compile the device code in each translation unit to self-contained kernels and embed them in the host object, so that the host object behaves like usual host object which can be linked by lld. The benefits of this feature is: 1. allow users to create static libraries which can be linked by host linker; 2. amortized device code linking time. This patch modifies HIP action builder to insert actions for linking device code and generating HIP fatbin, and pass HIP fatbin to host backend action. It extracts code for constructing command for generating HIP fatbin as a function so that it can be reused by early finalization. It also modifies codegen of HIP host constructor functions to embed the device fatbin when it is available. Differential Revision: https://reviews.llvm.org/D52377 llvm-svn: 343611
* Use the container form llvm::sort(C, ...)Fangrui Song2018-09-301-2/+2
| | | | | | | | | There are a few leftovers of rC343147 that are not (\w+)\.begin but in the form of ([-[:alnum:]>.]+)\.begin or spanning two lines. Change them to use the container form in this commit. The 12 occurrences have been inspected manually for safety. llvm-svn: 343425
* [analyzer] Provide an option to dump generated exploded graphs to a given file.George Karpenkov2018-09-281-0/+1
| | | | | | | | | | | Dumping graphs instead of opening them is often very useful, e.g. for transfer or converting to SVG. Basic sanity check for generated exploded graphs. Differential Revision: https://reviews.llvm.org/D52637 llvm-svn: 343352
* [modules] Frontend support for building a header module from a list ofRichard Smith2018-09-151-0/+3
| | | | | | headaer files. llvm-svn: 342304
* [clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstopMike Rice2018-09-111-0/+3
| | | | | | | | | | | | | With clang-cl, when the user specifies /Yc or /Yu without a filename the compiler uses a #pragma hdrstop in the main source file to determine the end of the PCH. If a header is specified with /Yc or /Yu #pragma hdrstop has no effect. The optional #pragma hdrstop filename argument is not yet supported. Differential Revision: https://reviews.llvm.org/D51391 llvm-svn: 341963
* Revert "[OPENMP][NVPTX] Disable runtime-type info for CUDA devices."Alexey Bataev2018-09-071-5/+0
| | | | | | Still need the RTTI for NVPTX target to pass sema checks. llvm-svn: 341668
* [MSan] add KMSAN support to Clang driverAlexander Potapenko2018-09-071-1/+3
| | | | | | | | | | | | | | | Boilerplate code for using KMSAN instrumentation in Clang. We add a new command line flag, -fsanitize=kernel-memory, with a corresponding SanitizerKind::KernelMemory, which, along with SanitizerKind::Memory, maps to the memory_sanitizer feature. KMSAN is only supported on x86_64 Linux. It's incompatible with other sanitizers, but supports code coverage instrumentation. llvm-svn: 341641
* [analyzer] Remove traces of ubigraph visualizationGeorge Karpenkov2018-09-061-2/+0
| | | | | | | | | | Ubigraph project has been dead since about 2008, and to the best of my knowledge, no one was using it. Previously, I wasn't able to launch the existing binary at all. Differential Revision: https://reviews.llvm.org/D51655 llvm-svn: 341601
* [OPENMP][NVPTX] Disable runtime-type info for CUDA devices.Alexey Bataev2018-09-051-0/+5
| | | | | | RTTI is not supported by the NVPTX target. llvm-svn: 341483
* [x86/SLH] Add a real Clang flag and LLVM IR attribute for SpeculativeChandler Carruth2018-09-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
* [DEBUGINFO] Add support for emission of the debug directives only.Alexey Bataev2018-08-311-0/+1
| | | | | | | | | | | | | | | | Summary: Added option -gline-directives-only to support emission of the debug directives only. It behaves very similar to -gline-tables-only, except that it sets llvm debug info emission kind to llvm::DICompileUnit::DebugDirectivesOnly. Reviewers: echristo Subscribers: aprantl, fedor.sergeev, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D51177 llvm-svn: 341212
* [OPENMP][NVPTX] Add options -f[no-]openmp-cuda-force-full-runtime.Alexey Bataev2018-08-301-1/+6
| | | | | | | Added options -f[no-]openmp-cuda-force-full-runtime to [not] force use of the full runtime for OpenMP offloading to CUDA devices. llvm-svn: 341073
* [analyzer] Move analyzer-eagerly-assume to AnalyzerOptions, enable by defaultGeorge Karpenkov2018-08-291-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D51251 llvm-svn: 340963
* Currently clang does not emit unused static constants. GCC emits theseElizabeth Andrews2018-08-221-0/+2
| | | | | | | | | | | | | | | | constants by default when there is no optimization. GCC's option -fno-keep-static-consts can be used to not emit unused static constants. In Clang, since default behavior does not keep unused static constants, -fkeep-static-consts can be used to emit these if required. This could be useful for producing identification strings like SVN identifiers inside the object file even though the string isn't used by the program. Differential Revision: https://reviews.llvm.org/D40925 llvm-svn: 340439
* [AArch64] Add Tiny Code Model for AArch64David Green2018-08-221-1/+1
| | | | | | | | Adds a tiny code model to Clang along side rL340397. Differential Revision: https://reviews.llvm.org/D49674 llvm-svn: 340398
* Add a new flag and attributes to control static destructor registrationErik Pilkington2018-08-211-0/+2
| | | | | | | | | | | | | | | | | | | | This commit adds the flag -fno-c++-static-destructors and the attributes [[clang::no_destroy]] and [[clang::always_destroy]]. no_destroy specifies that a specific static or thread duration variable shouldn't have it's destructor registered, and is the default in -fno-c++-static-destructors mode. always_destroy is the opposite, and is the default in -fc++-static-destructors mode. A variable whose destructor is disabled (either because of -fno-c++-static-destructors or [[clang::no_destroy]]) doesn't count as a use of the destructor, so we don't do any access checking or mark it referenced. We also don't emit -Wexit-time-destructors for these variables. rdar://21734598 Differential revision: https://reviews.llvm.org/D50994 llvm-svn: 340306
* DebugInfo: Add the ability to disable DWARF name tables entirelyDavid Blaikie2018-08-201-1/+7
| | | | | | | | | | | | | | | | | | This changes the current default behavior (from emitting pubnames by default, to not emitting them by default) & moves to matching GCC's behavior* with one significant difference: -gno(-gnu)-pubnames disables pubnames even in the presence of -gsplit-dwarf (though -gsplit-dwarf still by default enables -ggnu-pubnames). This allows users to disable pubnames (& the new DWARF5 accelerated access tables) when they might not be worth the size overhead. * GCC's behavior is that -ggnu-pubnames and -gpubnames override each other, and that -gno-gnu-pubnames and -gno-pubnames act as synonyms and disable either kind of pubnames if they come last. (eg: -gpubnames -gno-gnu-pubnames causes no pubnames (neither gnu or standard) to be emitted) llvm-svn: 340206
* Rename -mlink-cuda-bitcode to -mlink-builtin-bitcodeMatt Arsenault2018-08-201-2/+2
| | | | | | | The same semantics work for OpenCL, and probably any offload language. Keep the old name around as an alias. llvm-svn: 340193
* [AArch64] - return address signingLuke Cheeseman2018-08-171-0/+14
| | | | | | | | | | | | | | - Add a command line options -msign-return-address to enable return address signing - Armv8.3a added instructions to sign the return address to help mitigate against ROP attacks - This patch adds command line options to generate function attributes that signal to the back whether return address signing instructions should be added Differential revision: https://reviews.llvm.org/D49793 llvm-svn: 340019
* [ADT] Normalize empty triple componentsPetr Hosek2018-08-081-2/+1
| | | | | | | | | | | | | | | | | LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
* [OPENMP] Force OpenMP 4.5 when compiling for offloading.Alexey Bataev2018-07-261-4/+6
| | | | | | | If the user requested compilation for OpenMP with the offloading support, force the version of the OpenMP standard to 4.5 by default. llvm-svn: 338032
* [HIP] Support -fcuda-flush-denormals-to-zero for amdgcnYaxun Liu2018-07-211-4/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D48287 llvm-svn: 337639
* Change \t to spacesFangrui Song2018-07-201-1/+1
| | | | llvm-svn: 337530
* [clang]: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in as the function attribute "null-pointer-is-valid"="true". This CL only adds the attribute on the function. It also strips "nonnull" attributes from function arguments but keeps the related warnings unchanged. Corresponding LLVM change rL336613 already updated the optimizations to not treat null pointer dereferencing as undefined if the attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: jyknight Subscribers: drinkcat, xbolva00, cfe-commits Differential Revision: https://reviews.llvm.org/D47894 llvm-svn: 337433
* Re-land r337333, "Teach Clang to emit address-significance tables.",Peter Collingbourne2018-07-181-0/+2
| | | | | | | | | | | | | | | | | | | | | which was reverted in r337336. The problem that required a revert was fixed in r337338. Also added a missing "REQUIRES: x86-registered-target" to one of the tests. Original commit message: > Teach Clang to emit address-significance tables. > > By default, we emit an address-significance table on all ELF > targets when the integrated assembler is enabled. The emission of an > address-significance table can be controlled with the -faddrsig and > -fno-addrsig flags. > > Differential Revision: https://reviews.llvm.org/D48155 llvm-svn: 337339
* Revert r337333, "Teach Clang to emit address-significance tables."Peter Collingbourne2018-07-171-2/+0
| | | | | | | | | Causing multiple failures on sanitizer bots due to TLS symbol errors, e.g. /usr/bin/ld: __msan_origin_tls: TLS definition in /home/buildbots/ppc64be-clang-test/clang-ppc64be/stage1/lib/clang/7.0.0/lib/linux/libclang_rt.msan-powerpc64.a(msan.cc.o) section .tbss.__msan_origin_tls mismatches non-TLS reference in /tmp/lit_tmp_0a71tA/mallinfo-3ca75e.o llvm-svn: 337336
* Teach Clang to emit address-significance tables.Peter Collingbourne2018-07-171-0/+2
| | | | | | | | | | | By default, we emit an address-significance table on all ELF targets when the integrated assembler is enabled. The emission of an address-significance table can be controlled with the -faddrsig and -fno-addrsig flags. Differential Revision: https://reviews.llvm.org/D48155 llvm-svn: 337333
OpenPOWER on IntegriCloud