summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-0/+4
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* Revert "[X86] Add a Pass that builds a Condensed CFG for Load Value ↵Craig Topper2020-06-241-4/+0
| | | | | | | | | Injection (LVI) Gadgets" This reverts commit c74dd640fd740c6928f66a39c7c15a014af3f66f. Reverting to address coding standard issues raised in post-commit review.
* [X86] Add a Pass that builds a Condensed CFG for Load Value Injection (LVI) ↵Scott Constable2020-06-241-0/+4
| | | | | | | | | | | | | | Gadgets Adds a new data structure, ImmutableGraph, and uses RDF to find LVI gadgets and add them to a MachineGadgetGraph. More specifically, a new X86 machine pass finds Load Value Injection (LVI) gadgets consisting of a load from memory (i.e., SOURCE), and any operation that may transmit the value loaded from memory over a covert channel, or use the value loaded from memory to determine a branch/call target (i.e., SINK). Also adds a new target feature to X86: +lvi-load-hardening The feature can be added via the clang CLI using -mlvi-hardening. Differential Revision: https://reviews.llvm.org/D75936
* [X86] Add Indirect Thunk Support to X86 to mitigate Load Value Injection (LVI)Scott Constable2020-06-241-0/+4
| | | | | | | | | | | | | | | | | This pass replaces each indirect call/jump with a direct call to a thunk that looks like: lfence jmpq *%r11 This ensures that if the value in register %r11 was loaded from memory, then the value in %r11 is (architecturally) correct prior to the jump. Also adds a new target feature to X86: +lvi-cfi ("cfi" meaning control-flow integrity) The feature can be added via clang CLI using -mlvi-cfi. This is an alternate implementation to https://reviews.llvm.org/D75934 That merges the thunk insertion functionality with the existing X86 retpoline code. Differential Revision: https://reviews.llvm.org/D76812
* PR45000: Let Sema::SubstParmVarDecl handle default args of lambdas in ↵Aaron Puchert2020-05-061-4/+5
| | | | | | | | | | | | | | | | | | | | initializers Summary: We extend the behavior for local functions and methods of local classes to lambdas in variable initializers. The initializer is not a separate scope, but we treat it as such. We also remove the (faulty) instantiation of default arguments in TreeTransform::TransformLambdaExpr, because it doesn't do proper initialization, and if it did, we would do it twice (and thus also emit eventual errors twice). Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D76038 (cherry picked from commit f43859a099fa3587123717be941fa63ba8d0d4f2)
* [Sema] Allow function attribute patchable_function_entry on aarch64_beFangrui Song2020-05-061-1/+1
| | | | | | | | Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D79495 (cherry picked from commit 57a1c1be53aeea521747dd2f4b0097831341bea5)
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-191-2/+4
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* Revert "[Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Hans Wennborg2020-03-181-4/+2
| | | | | | | | | annotates an invalid template-id" We're not planning more release candidates for 10.0.0 at the moment, so reverting for now. This reverts commit 135744ce689569e7c64033bb5812572d3000239b.
* [Concepts] Fix incorrect control flow when TryAnnotateTypeConstraint ↵Saar Raz2020-03-171-2/+4
| | | | | | | | | | | | | annotates an invalid template-id TryAnnotateTypeConstraint could annotate a template-id which doesn't end up being a type-constraint, in which case control flow would incorrectly flow into ParseImplicitInt. Reenter the loop in this case. Enable relevant tests for C++20. This required disabling typo-correction during TryAnnotateTypeConstraint and changing a test case which is broken due to a separate bug (will be reported and handled separately). (cherry picked from commit 19fccc52ff2c1da1f93d9317c34769bd9bab8ac8)
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-124-11/+79
| | | | | | | | | | | | | | | | a dependent context. This matches the GCC behavior. We track the enclosing template depth when determining whether a statement expression is within a dependent context; there doesn't appear to be any other reliable way to determine this. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit 5c845c1c50ac89a6f12557d1571678f3d1432478)
* Revert "PR45083: Mark statement expressions as being dependent if they ↵Hans Wennborg2020-03-122-7/+7
| | | | | | | | | appear in" This turned out to cause problems, and was reverted on master together with its follow-up change in 66addf8e803618758457e4d578c5084e322ca448. This reverts commit 3a843031a5ad83a00d2603f623881cb2b2bf719d.
* PR45083: Mark statement expressions as being dependent if they appear inRichard Smith2020-03-042-7/+7
| | | | | | | | | | dependent contexts. We previously assumed they were neither value- nor instantiation-dependent under any circumstances, which would lead to crashes and other misbehavior. (cherry picked from commit bdad0a1b79273733df9acc1be4e992fa5d70ec56)
* Put microsoft template parameter shadow warning behind separate flag (PR44794)Hans Wennborg2020-02-262-2/+3
| | | | | | Differential revision: https://reviews.llvm.org/D75121 (cherry picked from commit 41a6612ea8afc5254e4de3aca55628d37f0be433)
* [remark][diagnostics] [codegen] Fix PR44896Rong Xu2020-02-261-0/+3
| | | | | | | | | | | | | | | | | This patch fixes PR44896. For IR input files, option fdiscard-value-names should be ignored as we need named values in loadModule(). Commit 60d3947922 sets this option after loadModule() where valued names already created. This creates an inconsistent state in setNameImpl() that leads to a seg fault. This patch forces fdiscard-value-names to be false for IR input files. This patch also emits a warning of "ignoring -fdiscard-value-names" if option fdiscard-value-names is explictly enabled in the commandline for IR input files. Differential Revision: https://reviews.llvm.org/D74878 (cherry picked from commit 11857d49948b845dcfd7c7f78595095e3add012d)
* Add -std=c++20 flag, replace C++2a with C++20 throughout the ClangRichard Smith2020-02-199-98/+103
| | | | | | | | | | | | | user interface and documentation, and update __cplusplus for C++20. WG21 considers the C++20 standard to be finished (even though it still has some more steps to pass through in the ISO process). The old flag names are accepted for compatibility, as usual, and we still have lots of references to C++2a in comments and identifiers; those can be cleaned up separately. (cherry picked from commit 24ad121582454e625bdad125c90d9ac0dae948c8)
* PR44890: Inherit explicitly-specified template arguments into base classRichard Smith2020-02-191-0/+7
| | | | | | deduction. (cherry picked from commit 34bd51f4b1d9f489e61becb662bdc72bb56dd277)
* [Clang] Limit -fintegrated-cc1 to only one TUAlexandre Ganea2020-02-131-7/+9
| | | | | | | | | | As discussed in https://reviews.llvm.org/D74447, this patch disables integrated-cc1 behavior if there's more than one job to be executed. This is meant to limit memory bloating, given that currently jobs don't clean up after execution (-disable-free is always active in cc1 mode). I see this behavior as temporary until release 10.0 ships (to ease merging of this patch), then we'll reevaluate the situation, see if D74447 makes more sense on the long term. Differential Revision: https://reviews.llvm.org/D74490 (cherry picked from commit 20f1abe306d030e99f56185a3aa077ffadf59b8a)
* [OpenCL] Restrict addr space conversions in nested pointersAnastasia Stulova2020-02-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | Address space conversion changes pointer representation. This commit disallows such conversions when they are not legal i.e. for the nested pointers even with compatible address spaces. Because the address space conversion in the nested levels can't be generated to modify the pointers correctly. The behavior implemented is as follows: - Any implicit conversions of nested pointers with different address spaces is rejected. - Any conversion of address spaces in nested pointers in safe casts (e.g. const_cast or static_cast) is rejected. - Conversion in low level C-style or reinterpret_cast is accepted but with a warning (this aligns with OpenCL C behavior). Fixes PR39674 Differential Revision: https://reviews.llvm.org/D73360 (cherry picked from commit 6064f426a18304e16b51cc79e74c9c2d55ef5a9c)
* Re-land "[Clang][Driver] Remove -M group options ..." and "[Clang] Avoid ↵Alexandre Ganea2020-02-102-0/+5
| | | | | | | | | | | crashing when generating crash diagnostics when '#pragma clang __debug ..." This re-lands commits f41ec709d9d388dc43469e6ac7f51b6313f7e4af (https://reviews.llvm.org/D74076) and commit 5fedc2b410853a6aef05e8edf19ebfc4e071e28f (https://reviews.llvm.org/D74070) The previous build break was caused by '#pragma clang __debug llvm_unreachable' used in a non-assert build. Move it to a separate test in crash-report-with-asserts.c. (cherry picked from commit 75f09b54429bee17a96e2ba7a2ac0f0a8a7f7e74)
* [Sema] Remove a -Wrange warning from -WallMark de Wever2020-02-032-5/+9
| | | | | | | | | | | | | | | | | | | | | | | During the review of D73007 Aaron Puchert mentioned `warn_for_range_variable_always_copy` shouldn't be part of -Wall since some coding styles require `for(const auto &bar : bars)`. This warning would cause false positives for these users. Based on Aaron's proposal refactored the warnings: * -Wrange-loop-construct warns about possibly unintended constructor calls. This is part of -Wall. It contains * warn_for_range_copy: loop variable A of type B creates a copy from type C * warn_for_range_const_reference_copy: loop variable A is initialized with a value of a different type resulting in a copy * -Wrange-loop-bind-reference warns about misleading use of reference types. This is not part of -Wall. It contains * warn_for_range_variable_always_copy: loop variable A is always a copy because the range of type B does not return a reference Differential Revision: https://reviews.llvm.org/D73434 (cherry picked from commit c03349e40f21f0375278138992a32694a99c830e)
* PR44723: Trigger return type deduction for operator<=>s whose returnRichard Smith2020-01-311-0/+6
| | | | | | | | | | types are needed to compute the return type of a defaulted operator<=>. This raises the question of what to do if return type deduction fails. The standard doesn't say, and implementations vary, so for now reject that case eagerly to keep our options open. (cherry picked from commit 42d4a55f227a1cc78ab8071062d869abe88655d9)
* [Concepts] Correctly form initial parameter mapping for parameter packs, ↵Saar Raz2020-01-312-5/+9
| | | | | | | | | | | | support substitution into SubstNonTypeTemplateParmExpr We previously would not correctly for the initial parameter mapping for variadic template parameters in Concepts. Testing this lead to the discovery that with the normalization process we would need to substitute into already-substituted-into template arguments, which means we need to add NonTypeTemplateParmExpr support to TemplateInstantiator. We do that by substituting into the replacement and the type separately, and then re-checking the expression against the NTTP with the new type, in order to form any new required implicit casts (for cases where the type of the NTTP was dependent). (cherry picked from commit ba1f3db4b0729ad932aa4f091e9578132d98a0c8)
* [Concept] Fix incorrect check for containsUnexpandedParameterPack in CSESaar Raz2020-01-301-0/+13
| | | | | | | | | | We previously checked for containsUnexpandedParameterPack in CSEs by observing the property in the converted arguments of the CSE. This may not work if the argument is an expanded type-alias that contains a pack-expansion (see added test). Check the as-written arguments when determining containsUnexpandedParameterPack and isInstantiationDependent. (cherry picked from commit c83d9bedc0cc430dc620e7a807daeb985d390325)
* [CUDA] Assume the latest known CUDA version if we've found an unknown one.Artem Belevich2020-01-293-1/+8
| | | | | | | | | | | | | | | | | This makes clang somewhat forward-compatible with new CUDA releases without having to patch it for every minor release without adding any new function. If an unknown version is found, clang issues a warning (can be disabled with -Wno-cuda-unknown-version) and assumes that it has detected the latest known version. CUDA releases are usually supersets of older ones feature-wise, so it should be sufficient to keep released clang versions working with minor CUDA updates without having to upgrade clang, too. Differential Revision: https://reviews.llvm.org/D73231 (cherry picked from commit 12fefeef203ab4ef52d19bcdbd4180608a4deae1)
* [Concepts] Transform constraints of non-template functions to ConstantEvaluatedSaar Raz2020-01-253-4/+17
| | | | | | | | | | We would previously try to evaluate atomic constraints of non-template functions as-is, and since they are now unevaluated at first, this would cause incorrect evaluation (bugs #44657, #44656). Substitute into atomic constraints of non-template functions as we would atomic constraints of template functions, in order to rebuild the expressions in a constant-evaluated context. (cherry picked from commit 713562f54858f10bf8998ee21ff2c7e7bad0d177)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-245-4/+6
| | | | | | | | | | __attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072 (cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
* [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2aSaar Raz2020-01-244-3/+5
| | | | | | | | | Now with concepts support merged and mostly complete, we do not need -fconcepts-ts (which was also misleading as we were not implementing the TS) and can enable concepts features under C++2a. A warning will be generated if users still attempt to use -fconcepts-ts. (cherry picked from commit 67c608a9695496cfc9d3fdf9d0b12b554ac6b4df)
* [Concepts] Placeholder constraints and abbreviated templatesSaar Raz2020-01-2415-68/+391
| | | | | | | | | | | | | | | | | | | | | | | This patch implements P1141R2 "Yet another approach for constrained declarations". General strategy for this patch was: - Expand AutoType to include optional type-constraint, reflecting the wording and easing the integration of constraints. - Replace autos in parameter type specifiers with invented parameters in GetTypeSpecTypeForDeclarator, using the same logic previously used for generic lambdas, now unified with abbreviated templates, by: - Tracking the template parameter lists in the Declarator object - Tracking the template parameter depth before parsing function declarators (at which point we can match template parameters against scope specifiers to know if we have an explicit template parameter list to append invented parameters to or not). - When encountering an AutoType in a parameter context we check a stack of InventedTemplateParameterInfo structures that contain the info required to create and accumulate invented template parameters (fields that were already present in LambdaScopeInfo, which now inherits from this class and is looked up when an auto is encountered in a lambda context). Resubmit after fixing MSAN failures caused by incomplete initialization of AutoTypeLocs in TypeSpecLocFiller. Differential Revision: https://reviews.llvm.org/D65042 (cherry picked from commit b481f028144ca91c15d1db3649ce14f174259e7e)
* [Concepts] Constraint Satisfaction CachingSaar Raz2020-01-245-23/+38
| | | | | | | | | | | Add a simple cache for constraint satisfaction results. Whether or not this simple caching would be permitted in final C++2a is currently being discussed but it is required for acceptable performance so we use it in the meantime, with the possibility of adding some cache invalidation mechanisms later. Differential Revision: https://reviews.llvm.org/D72552 (cherry picked from commit b933d37cd3774e5431b35e82187eebb59b1ff59e)
* [Concepts] Requires ExpressionsSaar Raz2020-01-2416-106/+800
| | | | | | | | | | Implement support for C++2a requires-expressions. Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair. Differential Revision: https://reviews.llvm.org/D50360 (cherry picked from commit a0f50d731639350c7a79f140f026c27a18215531)
* Remove redundant CXXScopeSpec from TemplateIdAnnotation.Richard Smith2020-01-243-21/+17
| | | | | | | | | | | | | | A TemplateIdAnnotation represents only a template-id, not a nested-name-specifier plus a template-id. Don't make a redundant copy of the CXXScopeSpec and store it on the template-id annotation. This slightly improves error recovery by more properly handling the case where we would form an invalid CXXScopeSpec while parsing a typename specifier, instead of accidentally putting the token stream into a broken "annot_template_id with a scope specifier, but with no preceding annot_cxxscope token" state. (cherry picked from commit a42fd84cff265b7e9faa3fe42885ee171393e4db)
* Revert "PR17164: Change clang's default behavior from ↵Mitch Phillips2020-01-231-1/+1
| | | | | | | | | | | | -flax-vector-conversions=all to -flax-vector-conversions=integer." This patch broke the Sanitizer buildbots. Please see the commit's differential revision for more information (https://reviews.llvm.org/D67678). This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486. (cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
* Clang] Fix expansion of response files in -Wp after integrated-cc1 changeAlexandre Ganea2020-01-231-1/+1
| | | | | | | | | | After rGb4a99a061f517e60985667e39519f60186cbb469, passing a response file such as -Wp,@a.rsp wasn't working anymore because .rsp expansion happens inside clang's main() function. This patch adds response file expansion in the -cc1 tool. Differential Revision: https://reviews.llvm.org/D73120 (cherry picked from commit 68d7f06092e56b17eb0cddf560a9d9fe8afb7dd8)
* Revert 9007f06af0e "Revert "Allow system header to provide their own ↵Hans Wennborg2020-01-171-0/+3
| | | | | | | implementation of some builtin"" This should no longer be necessary after cd4c65f91d5 "Add __warn_memset_zero_len builtin as a workaround for glibc issue"
* Revert "Allow system header to provide their own implementation of some builtin"Amy Huang2020-01-171-3/+0
| | | | | | | | | This reverts commit 921f871ac438175ca8fcfcafdfcfac4d7ddf3905 because it causes libc++ code to trigger __warn_memset_zero_len. See https://reviews.llvm.org/D71082. (cherry picked from commit 3d210ed3d1880c615776b07d1916edb400c245a6)
* Add __warn_memset_zero_len builtin as a workaround for glibc issueserge-sans-paille2020-01-171-0/+3
| | | | | | | | | Glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=25399 The fix consist in considering the missing function as a builtin lowered to a nop. Differential Revision: https://reviews.llvm.org/D72869 (cherry picked from commit d293417931d3a9d46799b42795988ca3b5cfd766)
* PR42694 Support explicit(bool) in older language modes as an extension.Richard Smith2020-01-172-4/+24
| | | | | | | | This needs somewhat careful disambiguation, as C++2a explicit(bool) is a breaking change. We only enable it in cases where the source construct could not possibly be anything else. (cherry picked from commit 45d70806f4386adfb62b0d75949a8aad58e0576f)
* PR17164: Change clang's default behavior from -flax-vector-conversions=all ↵Richard Smith2020-01-171-1/+1
| | | | | | | | | | | | | | | | | | to -flax-vector-conversions=integer. Summary: See proposal on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html Reviewers: SjoerdMeijer, eli.friedman Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67678 (cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
* Replace CLANG_SPAWN_CC1 env var with a driver mode flagNico Weber2020-01-161-0/+8
| | | | | | | | | | | | | | | | | | Flags are clang's default UI is flags. We can have an env var in addition to that, but in D69825 nobody has yet mentioned why this needs an env var, so omit it for now. If someone needs to set the flag via env var, the existing CCC_OVERRIDE_OPTIONS mechanism works for it (set CCC_OVERRIDE_OPTIONS=+-fno-integrated-cc1 for example). Also mention the cc1-in-process change in the release notes. Also spruce up the test a bit so it actually tests something :) Differential Revision: https://reviews.llvm.org/D72769 (cherry picked from commit 8e5018e990b701391e6c33ba85b012343df67272)
* Fix Wdocumentation warning. NFC.Simon Pilgrim2020-01-151-2/+0
|
* [Driver][X86] Add -malign-branch* and -mbranches-within-32B-boundariesFangrui Song2020-01-142-0/+7
| | | | | | | | These driver options perform some checking and delegate to MC options -x86-align-branch* and -x86-branches-within-32B-boundaries. Reviewed By: skan Differential Revision: https://reviews.llvm.org/D72463
* [Concepts] Type ConstraintsSaar Raz2020-01-1511-102/+365
| | | | | | | Add support for type-constraints in template type parameters. Also add support for template type parameters as pack expansions (where the type constraint can now contain an unexpanded parameter pack). Differential Revision: https://reviews.llvm.org/D44352
* [X86] ABI compat bugfix for MSVC vectorcallReid Kleckner2020-01-141-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, X86_32ABIInfo::classifyArgument would be called twice on vector arguments to vectorcall functions. This function has side effects to track GPR register usage, and this would lead to incorrect GPR usage in some cases. The specific case I noticed is from running out of XMM registers with mixed FP and vector arguments and no aggregates of any kind. Consider this prototype: void __vectorcall vectorcall_indirect_vec( double xmm0, double xmm1, double xmm2, double xmm3, double xmm4, __m128 xmm5, __m128 ecx, int edx, __m128 mem); classifyArgument has no effects when called on a plain FP type, but when called on a vector type, it modifies FreeRegs to model GPR consumption. However, this should not happen during the vector call first pass. I refactored the code to unify vectorcall HVA logic with regcall HVA logic. The conventions pass HVAs in registers differently (expanded vs. not expanded), but if they do not fit in registers, they both pass them indirectly by address. Reviewers: erichkeane, craig.topper Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72110
* [Driver] Ignore -fno-semantic-interpositionFangrui Song2020-01-141-0/+1
| | | | | | | | | | | | | | | | | | Fedora wants to build projects with -fno-semantic-interposition (e.g. https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup), which is supported by GCC>=5. Clang's current behavior is similar to -fno-semantic-interposition and the end goal is to make it more so (https://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html). Ignore this option. We should let users know -fsemantic-interposition is not currently supported, so it should remain a hard error. Reviewed By: serge-sans-paille Differential Revision: https://reviews.llvm.org/D72724
* Removed PointerUnion3 and PointerUnion4 aliases in favor of the variadic ↵Dmitri Gribenko2020-01-145-12/+12
| | | | template
* [Syntax] Mark synthesized nodes as modifiableIlya Biryukov2020-01-141-0/+2
| | | | | This was an oversight in the original patch. Also add corresponding tests.
* [Syntax] Assert invariants on tree structure and fix a bug in mutationsIlya Biryukov2020-01-141-0/+6
| | | | | | | | Add checks for some structural invariants when building and mutating the syntax trees. Fix a bug failing the invariants after mutations: the parent of nodes added into the tree was null.
* [ARM,MVE] Use the new Tablegen `defvar` and `if` statements.Simon Tatham2020-01-141-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This cleans up a lot of ugly `foreach` bodges that I've been using to work around the lack of those two language features. Now they both exist, I can make then all into something more legible! In particular, in the common pattern in `ARMInstrMVE.td` where a multiclass defines an `Instruction` instance plus one or more `Pat` that select it, I've used a `defvar` to wrap `!cast<Instruction>(NAME)` so that the patterns themselves become a little more legible. Replacing a `foreach` with a `defvar` removes a level of block structure, so several pieces of code have their indentation changed by this patch. Best viewed with whitespace ignored. NFC: the output of `llvm-tblgen -print-records` on the two affected Tablegen sources is exactly identical before and after this change, so there should be no effect at all on any of the other generated files. Reviewers: MarkMurrayARM, miyuki Reviewed By: MarkMurrayARM Subscribers: kristof.beyls, hiraditya, dmgreen, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72690
* [DebugInfo] Add another level to DebugInfoKind called ConstructorAmy Huang2020-01-132-0/+10
| | | | | | | | | The option will limit debug info by only emitting complete class type information when its constructor is emitted. This patch changes comparisons with LimitedDebugInfo to use the new level instead. Differential Revision: https://reviews.llvm.org/D72427
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-133-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
OpenPOWER on IntegriCloud