summaryrefslogtreecommitdiffstats
path: root/clang/lib/Frontend
Commit message (Collapse)AuthorAgeFilesLines
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-3/+13
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. llvm-svn: 371817
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-131-13/+3
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. llvm-svn: 371813
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-3/+13
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. llvm-svn: 371805
* Revert r371785.Manoj Gupta2019-09-131-7/+0
| | | | | | r371785 is causing fails on clang-hexagon-elf buildbots. llvm-svn: 371799
* Add -Wpoison-system-directories warningManoj Gupta2019-09-121-0/+7
| | | | | | | | | | | | | | | | | | When using clang as a cross-compiler, we should not use system headers to do the compilation. This CL adds support of a new warning flag -Wpoison-system-directories which emits warnings if --sysroot is set and headers from common host system location are used. By default the warning is disabled. The intention of the warning is to catch bad includes which are usually generated by third party build system not targeting cross-compilation. Such cases happen in Chrome OS when someone imports a new package or upgrade one to a newer version from upstream. Patch by: denik (Denis Nikitin) llvm-svn: 371785
* [analyzer][NFC] Fix inconsistent references to checkers as "checks"Kristof Umann2019-09-121-1/+1
| | | | | | | | | | | | | | Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks. This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks. Differential Revision: https://reviews.llvm.org/D67140 llvm-svn: 371760
* Removed some questionable default arguments from settersDmitri Gribenko2019-09-121-1/+1
| | | | | | | | | | | | | | | | | Summary: They can be confusing -- what does it mean to call a setter without a value? Also, some setters, like `setPrintTemplateTree` had `false` as the default value! The callers are largely not using these default arguments anyway. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67491 llvm-svn: 371731
* [WebAssembly] Add -fwasm-exceptions for wasm EHHeejin Ahn2019-09-121-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds `-fwasm-exceptions` (in similar fashion with `-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything with wasm exception handling from the frontend to the backend. We currently have `-mexception-handling` in clang frontend, but this is only about the architecture capability and does not turn on other necessary options such as the exception model in the backend. (This can be turned on with `llc -exception-model=wasm`, but llc is not invoked separately as a command line tool, so this option has to be transferred from clang.) Turning on `-fwasm-exceptions` in clang also turns on `-mexception-handling` if not specified, and will error out if `-mno-exception-handling` is specified. Reviewers: dschuff, tlively, sbc100 Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67208 llvm-svn: 371708
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-111-3/+0
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-101-3/+0
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [clang][DependencyFileGenerator] Fix missing -MT option handlingJan Korous2019-09-072-5/+5
| | | | | | | | Targets in DependencyFileGenerator don't necessarily come from -MT option. Differential Revision: https://reviews.llvm.org/D67308 llvm-svn: 371279
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-0/+2
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* [c++20] P1143R2: Add support for the C++20 'constinit' keyword.Richard Smith2019-09-041-1/+3
| | | | | | | | | | | | | This is mostly the same as the [[clang::require_constant_initialization]] attribute, but has a couple of additional syntactic and semantic restrictions. In passing, I added a warning for the attribute form being added after we have already seen the initialization of the variable (but before we see the definition); that case previously slipped between the cracks and the attribute was silently ignored. llvm-svn: 370972
* [Driver] Use shared singleton instance of DriverOptTableIlya Biryukov2019-09-041-4/+4
| | | | | | | | | | | | | | | | | | | | | Summary: This significantly reduces the time required to run clangd tests, by ~10%. Should also have an effect on other tests that run command-line parsing multiple times inside a single invocation. Reviewers: gribozavr, sammccall Reviewed By: sammccall Subscribers: kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67163 llvm-svn: 370908
* Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev2019-09-041-4/+0
| | | | | | | | | Breaks BUILD_SHARED_LIBS build, introduces cycles in library dependency graphs. (clangInterp depends on clangAST which depends on clangInterp) This reverts r370839, which is an yet another recommit of D64146. llvm-svn: 370874
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-041-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370839
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-4/+0
| | | | | | This reverts r370636 (git commit 8327fed9475a14c3376b4860c75370c730e08f33) llvm-svn: 370642
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370636
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-4/+0
| | | | | | This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) llvm-svn: 370588
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370584
* Introduce a DirectoryEntryRef that stores both a reference and anAlex Lorenz2019-08-311-1/+1
| | | | | | | | | | | | | | accessed name to the directory entry This commit introduces a parallel API that returns a DirectoryEntryRef to the FileManager, similar to the parallel FileEntryRef API. All uses will have to be update in follow-up patches. The immediate use of the new API in this patch fixes the issue where a file manager was reused in clang-scan-deps, but reported an different file path whenever a framework lookup was done through a symlink. Differential Revision: https://reviews.llvm.org/D67026 llvm-svn: 370562
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-4/+0
| | | | | | This reverts r370531 (git commit d4c1002e0bbbbab50f6891cdd2f5bd3a8f3a3584) llvm-svn: 370535
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370531
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-4/+0
| | | | | | This reverts r370476 (git commit a5590950549719d0d9ea69ed164b0c8c0f4e02e6) llvm-svn: 370481
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+4
| | | | | | | | | | | | | | | | | | Summary: This patch introduces the skeleton of the constexpr interpreter, capable of evaluating a simple constexpr functions consisting of if statements. The interpreter is described in more detail in the RFC. Further patches will add more features. Reviewers: Bigcheese, jfb, rsmith Subscribers: bruno, uenoku, ldionne, Tyker, thegameg, tschuett, dexonsmith, mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64146 llvm-svn: 370476
* [preprocessor] Add an opportunity to retain excluded conditional blocksEvgeny Mankov2019-08-271-0/+2
| | | | | | | | | | | | | | It is handy for clang tooling, for instance, in source to source transformation. Reviewers: vpykhtin (Valery Pykhtin), erichkeane (Erich Keane) Subscribers: rsmith (Richard Smith), akyrtzi (Argyrios Kyrtzidis) Tags: #clang Differential Revision: https://reviews.llvm.org/D66597 llvm-svn: 370123
* ArrayRef'ized CompilerInvocation::CreateFromArgsDmitri Gribenko2019-08-272-8/+4
| | | | | | | | | | Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66797 llvm-svn: 370122
* Use FileEntryRef for PPCallbacks::HasIncludeAlex Lorenz2019-08-271-1/+1
| | | | | | | | This fixes the issue where a filename dependendency was missing if the file that was referenced with __has_include() was accessed through a symlink in an earlier run, if the file manager was reused between runs. llvm-svn: 370081
* [Driver] Add an option for createInvocationFromCommandLine to recover on errorsIlya Biryukov2019-08-271-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, it would always return nullptr on any error. This change adds a parameter, controlling whether the function should attempt to return a non-null result even if unknown arguments (or other errors were encountered). The new behavior is only used in clangd. Considered an alternative of changing the return value instead of adding a new parameter, but that would require updating all callsites. Settled with the parameter to minimize the code changes. Reviewers: gribozavr Reviewed By: gribozavr Subscribers: nridge, jkorous, arphaman, kadircet, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66731 llvm-svn: 370033
* Use FileEntryRef for PPCallbacks::FileSkippedAlex Lorenz2019-08-272-4/+4
| | | | | | | | This fixes the issue where a filename dependendency was missing if the file that was skipped was included through a symlink in an earlier run, if the file manager was reused between runs. llvm-svn: 369998
* FileManager: Use llvm::Expected in new getFileRef APIDuncan P. N. Exon Smith2019-08-261-0/+2
| | | | | | | | | | | | | | | | | | | | | `FileManager::getFileRef` is a modern API which we expect to convert to over time. We should modernize the error handling as well, using `llvm::Expected` instead of `llvm::ErrorOr`, to help clients that care about errors to ensure nothing is missed. However, not all clients care. I've also added another path for those that don't: - `FileEntryRef` is now copy- and move-assignable (using a pointer instead of a reference). - `FileManager::getOptionalFileRef` returns an `llvm::Optional` instead of `llvm::Expected`. - Added an `llvm::expectedToOptional` utility in case this is useful elsewhere. https://reviews.llvm.org/D66705 llvm-svn: 369943
* Improve behavior in the case of stack exhaustion.Richard Smith2019-08-261-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Clang performs various recursive operations (such as template instantiation), and may use non-trivial amounts of stack space in each recursive step (for instance, due to recursive AST walks). While we try to keep the stack space used by such steps to a minimum and we have explicit limits on the number of such steps we perform, it's impractical to guarantee that we won't blow out the stack on deeply recursive template instantiations on complex ASTs, even with only a moderately high instantiation depth limit. The user experience in these cases is generally terrible: we crash with no hint of what went wrong. Under this patch, we attempt to do better: * Detect when the stack is nearly exhausted, and produce a warning with a nice template instantiation backtrace, telling the user that we might run slowly or crash. * For cases where we're forced to trigger recursive template instantiation in arbitrarily-deeply-nested contexts, check whether we're nearly out of stack space and allocate a new stack (by spawning a new thread) after producing the warning. Reviewers: rnk, aaron.ballman Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66361 llvm-svn: 369940
* [analyzer] Analysis: Fix checker silencingCsaba Dabis2019-08-241-24/+27
| | | | llvm-svn: 369845
* Do a sweep of symbol internalization. NFC.Benjamin Kramer2019-08-231-0/+2
| | | | llvm-svn: 369803
* [clang][ifs] Dropping older experimental interface stub formats.Puyan Lotfi2019-08-222-149/+21
| | | | | | | | | | | | I've been working on a new tool, llvm-ifs, for merging interface stub files generated by clang and I've iterated on my derivative format of TBE to a newer format. llvm-ifs will only support the new format, so I am going to drop the older experimental interface stubs formats in this commit to make things simpler. Differential Revision: https://reviews.llvm.org/D66573 llvm-svn: 369719
* [clang][ifs] New interface stubs format (llvm triple based).Puyan Lotfi2019-08-222-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | After posting llvm-ifs on phabricator, I made some progress in hardening up how I think the format for Interface Stubs should look. There are a number of things I think the TBE format was missing (no endianness, no info about the Object Format because it assumes ELF), so I have added those and broken off from being as similar to the TBE schema. In a subsequent commit I can drop the other formats. An example of how The format will look is as follows: --- !experimental-ifs-v1 IfsVersion: 1.0 Triple: x86_64-unknown-linux-gnu ObjectFileFormat: ELF Symbols: _Z9nothiddenv: { Type: Func } _Z10cmdVisiblev: { Type: Func } ... The format is still marked experimental. Differential Revision: https://reviews.llvm.org/D66446 llvm-svn: 369715
* Introduce FileEntryRef and use it when handling includes to report correct ↵Alex Lorenz2019-08-225-21/+26
| | | | | | | | | | | | | | | | | | | | | | | dependencies when the FileManager is reused across invocations This commit introduces a parallel API to FileManager's getFile: getFileEntryRef, which returns a reference to the FileEntry, and the name that was used to access the file. In the case of a VFS with 'use-external-names', the FileEntyRef contains the external name of the file, not the filename that was used to access it. The new API is adopted only in the HeaderSearch and Preprocessor for include file lookup, so that the accessed path can be propagated to SourceManager's FileInfo. SourceManager's FileInfo now can report this accessed path, using the new getName method. This API is then adopted in the dependency collector, which now correctly reports dependencies when a file is included both using a symlink and a real path in the case when the FileManager is reused across multiple Preprocessor invocations. Note that this patch does not fix all dependency collector issues, as the same problem is still present in other cases when dependencies are obtained using FileSkipped, InclusionDirective, and HasInclude. This will be fixed in follow-up commits. Differential Revision: https://reviews.llvm.org/D65907 llvm-svn: 369680
* Implement P1668R1Erich Keane2019-08-191-0/+1
| | | | | | | Allow inline assembly statements in unexecuted branches of constexpr functions. llvm-svn: 369281
* [analyzer] Analysis: Silence checkersCsaba Dabis2019-08-161-7/+33
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces a new `analyzer-config` configuration: `-analyzer-config silence-checkers` which could be used to silence the given checkers. It accepts a semicolon separated list, packed into quotation marks, e.g: `-analyzer-config silence-checkers="core.DivideZero;core.NullDereference"` It could be used to "disable" core checkers, so they model the analysis as before, just if some of them are too noisy it prevents to emit reports. This patch also adds support for that new option to the scan-build. Passing the option `-disable-checker core.DivideZero` to the scan-build will be transferred to `-analyzer-config silence-checkers=core.DivideZero`. Reviewed By: NoQ, Szelethus Differential Revision: https://reviews.llvm.org/D66042 llvm-svn: 369078
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1421-57/+57
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368942
* [OpenCL] Fix lang mode predefined macros for C++ mode.Anastasia Stulova2019-08-121-9/+9
| | | | | | | | | | | | | In C++ mode we should only avoid adding __OPENCL_C_VERSION__, all other predefined macros about the language mode are still valid. This change also fixes the language version check in the headers accordingly. Differential Revision: https://reviews.llvm.org/D65941 llvm-svn: 368552
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
* [clang] Add no-warn support for WaBrian Cain2019-08-081-0/+1
| | | | llvm-svn: 368328
* Remove LLVM mutexes from clang in favor of std::mutexBenjamin Kramer2019-08-071-5/+4
| | | | | | | None of those need to be recursive mutexes. No functionality change intended. llvm-svn: 368173
* [OPENMP]Set default version to OpenMP 4.5.Alexey Bataev2019-08-072-7/+7
| | | | | | | Since clang fully supports OpenMP 4.5, set the default version to 4.5 instead of 3.1. llvm-svn: 368172
* [OPENMP]Add standard macro value _OPENMP for OpenMP 5.0.Alexey Bataev2019-08-071-0/+3
| | | | | | | | | According to the OpenMP standard, compiler must define _OPENMP macro, which has value in format yyyymm, where yyyy is the year of the standard and mm is the month of the standard. For OpenMP 5.0 this value must be set to 201811. llvm-svn: 368170
* Replace non-recursive sys::Mutex users with std::mutexBenjamin Kramer2019-08-071-5/+5
| | | | | | | Also remove a use of sys::MutexImpl, that's just evil. No functionality change intended. llvm-svn: 368157
OpenPOWER on IntegriCloud