summaryrefslogtreecommitdiff
path: root/include/clang/Basic/DiagnosticASTKinds.td
Commit message (Collapse)AuthorAgeFilesLines
* PR43629: Fix crash evaluating constexpr placement new on a subobject ofRichard Smith2019-10-101-1/+2
| | | | | | an out-of-lifetime object. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374465 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: support placement new-expressions in constant evaluation.Richard Smith2019-10-031-15/+29
| | | | | | | | | For now, we restrict this support to use from within the standard library implementation, since we're required to make parts of the standard library that use placement new work, but not permitted to make uses of placement new from user code work. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373547 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: allow direct calls to operator new / operator delete fromRichard Smith2019-10-031-2/+13
| | | | | | std::allocator::{allocate,deallocate} in constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373546 91177308-0d34-0410-b5e6-96231b3b80d8
* For now, disallow lifetime-extended temporaries with non-trivial (butRichard Smith2019-09-291-0/+3
| | | | | | | | | | | | constexpr) destructors from being used in the values of constexpr variables. The standard rules here are unclear at best, so rejecting the problematic cases seems prudent. Prior to this change, we would fail to run the destructors for these temporaries, even if they had side-effects, which is certainly not the right behavior. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373161 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-291-2/+4
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373159 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: add support for explicit destructor calls andRichard Smith2019-09-271-14/+21
| | | | | | pseudo-destructor calls in constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373122 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: Add support for dynamic allocation with new / delete duringRichard Smith2019-09-271-0/+44
| | | | | | constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@373036 91177308-0d34-0410-b5e6-96231b3b80d8
* For P0784R7: add support for constexpr destructors, and call them asRichard Smith2019-09-231-0/+2
| | | | | | | | | | | appropriate during constant evaluation. Note that the evaluator is sometimes invoked on incomplete expressions. In such cases, if an object is constructed but we never reach the point where it would be destroyed (and it has non-trivial destruction), we treat the expression as having an unmodeled side-effect. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372538 91177308-0d34-0410-b5e6-96231b3b80d8
* Clean out unused diagnostics. NFC.Benjamin Kramer2019-09-191-1/+0
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372319 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1331R2: Allow transient use of uninitialized objects inRichard Smith2019-09-181-20/+24
| | | | | | constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@372237 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-131-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@371834 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[Clang Interpreter] Initial patch for the constexpr interpreter"Roman Lebedev2019-09-041-2/+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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370874 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-041-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370839 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-2/+0
| | | | | | This reverts r370636 (git commit 8327fed9475a14c3376b4860c75370c730e08f33) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370642 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-09-021-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370636 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-2/+0
| | | | | | This reverts r370584 (git commit afcb3de117265a69d21e5673356e925a454d7d02) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370588 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-311-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370584 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-2/+0
| | | | | | This reverts r370531 (git commit d4c1002e0bbbbab50f6891cdd2f5bd3a8f3a3584) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370535 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370531 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-2/+0
| | | | | | This reverts r370476 (git commit a5590950549719d0d9ea69ed164b0c8c0f4e02e6) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370481 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang Interpreter] Initial patch for the constexpr interpreterNandor Licker2019-08-301-0/+2
| | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370476 91177308-0d34-0410-b5e6-96231b3b80d8
* [C++2a] Add __builtin_bit_cast, used to implement std::bit_castErik Pilkington2019-07-021-0/+13
| | | | | | | | | | | | | | | | | | This commit adds a new builtin, __builtin_bit_cast(T, v), which performs a bit_cast from a value v to a type T. This expression can be evaluated at compile time under specific circumstances. The compile time evaluation currently doesn't support bit-fields, but I'm planning on fixing this in a follow up (some of the logic for figuring this out is in CodeGen). I'm also planning follow-ups for supporting some more esoteric types that the constexpr evaluator supports, as well as extending __builtin_memcpy constexpr evaluation to use the same infrastructure. rdar://44987528 Differential revision: https://reviews.llvm.org/D62825 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@364954 91177308-0d34-0410-b5e6-96231b3b80d8
* [clang] perform semantic checking in constant contextGauthier Harnisch2019-06-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Since the addition of __builtin_is_constant_evaluated the result of an expression can change based on whether it is evaluated in constant context. a lot of semantic checking performs evaluations with out specifying context. which can lead to wrong diagnostics. for example: ``` constexpr int i0 = (long long)__builtin_is_constant_evaluated() * (1ll << 33); //#1 constexpr int i1 = (long long)!__builtin_is_constant_evaluated() * (1ll << 33); //#2 ``` before the patch, #2 was diagnosed incorrectly and #1 wasn't diagnosed. after the patch #1 is diagnosed as it should and #2 isn't. Changes: - add a flag to Sema to passe in constant context mode. - in SemaChecking.cpp calls to Expr::Evaluate* are now done in constant context when they should. - in SemaChecking.cpp diagnostics for UB are not checked for in constant context because an error will be emitted by the constant evaluator. - in SemaChecking.cpp diagnostics for construct that cannot appear in constant context are not checked for in constant context. - in SemaChecking.cpp diagnostics on constant expression are always emitted because constant expression are always evaluated. - semantic checking for initialization of constexpr variables is now done in constant context. - adapt test that were depending on warning changes. - add test. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62009 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@363488 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1330R0: permit simple-assignments that change the active memberRichard Smith2019-05-211-0/+2
| | | | | | of a union within constant expression evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361329 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor: split Uninitialized state on APValue into an "Absent" stateRichard Smith2019-05-211-1/+2
| | | | | | | representing no such object, and an "Indeterminate" state representing an uninitialized object. The latter is not yet used, but soon will be. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361328 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-13/+15
| | | | | | | | | class type in constant evaluation. This reinstates r360977, reverted in r360987, now that its rerequisite patch is reinstated and fixed. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361067 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+3
| | | | | | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) This reinstates r360974, reverted in r360988, with a fix for a static_assert failure on 32-bit builds: force Type base class to have 8-byte alignment like the rest of Clang's AST nodes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360995 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert Refactor constant evaluation of typeid(T) to track a symbolic ↵Chris Bieneman2019-05-171-3/+0
| | | | | | | | type_info object rather than tracking the originating expression. This reverts r360974 (git commit 7ee4307bd4450022c3c8777f43a40cc4f0ccc009) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360988 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert [c++20] P1327R1: Support for typeid applied to objects of polymorphic ↵Chris Bieneman2019-05-171-15/+13
| | | | | | | | class type in constant evaluation. This reverts r360977 (git commit f51dc8d2f98f4029247552bc45ef53628ab3b6b9) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360987 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1327R1: Support for typeid applied to objects of polymorphicRichard Smith2019-05-171-13/+15
| | | | | | class type in constant evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360977 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor constant evaluation of typeid(T) to track a symbolic type_infoRichard Smith2019-05-171-0/+3
| | | | | | | | | | object rather than tracking the originating expression. This is groundwork for supporting polymorphic typeid expressions. (Note that this somewhat regresses our support for DR1968, but it turns out that that never actually worked anyway, at least in non-trivial cases.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360974 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] For P1327R1: support dynamic_cast in constant expressionRichard Smith2019-05-151-12/+26
| | | | | | evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360806 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-0/+4
| | | | | | | | | | | | | evaluation. This reinstates r360559, reverted in r360580, with a fix to avoid crashing if evaluation-for-overflow mode encounters a virtual call on an object of a class with a virtual base class, and to generally not try to resolve virtual function calls to objects whose (notional) vptrs are not readable. (The standard rules are unclear here, but this seems like a reasonable approach.) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360635 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r360559 "[c++20] P1064R0: Allow virtual function calls in constant ↵Hans Wennborg2019-05-131-2/+0
| | | | | | | | | expression evaluation." This caused Chromium builds to hit the new "can't handle virtual calls with virtual bases" assert. Reduced repro coming up. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360580 91177308-0d34-0410-b5e6-96231b3b80d8
* [c++20] P1064R0: Allow virtual function calls in constant expressionRichard Smith2019-05-131-0/+2
| | | | | | evaluation. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360559 91177308-0d34-0410-b5e6-96231b3b80d8
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-121-12/+12
| | | | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. This reinstates r360499, reverted in r360531. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360538 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-121-0/+2
| | | | | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. This reinstates r360464 (reverted in r360531) with a workaround for an MSVC bug that previously caused the Windows bots to fail. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360537 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert rL360499 and rL360464 from cfe/trunk:Simon Pilgrim2019-05-111-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | Reject attempts to call non-static member functions on objects outside their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. ........ Fix handling of objects under construction during constant expression evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. ........ Fixes windows buildbots git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360531 91177308-0d34-0410-b5e6-96231b3b80d8
* Reject attempts to call non-static member functions on objects outsideRichard Smith2019-05-111-12/+12
| | | | | | | | | | | | | | their lifetime in constant expressions. This is undefined behavior per [class.cdtor]p2. We continue to allow this for objects whose values are not visible within the constant evaluation, because there's no way we can tell whether the access is defined or not, existing code relies on the ability to make such calls, and every other compiler allows such calls. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360499 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix handling of objects under construction during constant expressionRichard Smith2019-05-101-0/+2
| | | | | | | | | | evaluation. It's not enough to just track the LValueBase that we're evaluating, we need to also track the path to the objects whose constructors are running. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360464 91177308-0d34-0410-b5e6-96231b3b80d8
* DR1872: don't allow any calls to virtual functions in constantRichard Smith2019-05-091-1/+1
| | | | | | | | evaluation. Not even in cases where we would not actually perform virtual dispatch. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360370 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASTImporter] Make ODR error handling configurableGabor Marton2019-04-011-5/+67
| | | | | | | | | | | | | | | | | | | | | Summary: ODR errors are not necessarily true errors during the import of ASTs. ASTMerge and CrossTU should use the warning equivalent of every CTU error, while Sema should emit errors as before. Reviewers: martong, a_sidorin, shafik, a.sidorin Reviewed By: a_sidorin Subscribers: rnkovacs, dkrupp, Szelethus, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58897 Patch by Endre Fulop! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@357394 91177308-0d34-0410-b5e6-96231b3b80d8
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix up diagnostics.Richard Trieu2018-12-141-0/+30
| | | | | | | | | | | | Move some diagnostics around between Diagnostic*Kinds.td files. Diagnostics used in multiple places were moved to DiagnosticCommonKinds.td. Diagnostics listed in the wrong place (ie, Sema diagnostics listed in DiagnosticsParseKinds.td) were moved to the correct places. One diagnostic split into two so that the diagnostic string is in the .td file instead of in code. Cleaned up the diagnostic includes after all the changes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349125 91177308-0d34-0410-b5e6-96231b3b80d8
* [ExprConstant] Improve memchr/memcmp for type mismatch and multibyte element ↵Hubert Tong2018-12-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | types Summary: `memchr` and `memcmp` operate upon the character units of the object representation; that is, the `size_t` parameter expresses the number of character units. The constant folding implementation is updated in this patch to account for multibyte element types in the arrays passed to `memchr`/`memcmp` and, in the case of `memcmp`, to account for the possibility that the arrays may have differing element types (even when they are byte-sized). Actual inspection of the object representation is not implemented. Comparisons are done only between elements with the same object size; that is, `memchr` will fail when inspecting at least one character unit of a multibyte element. The integer types are assumed to have two's complement representation with 0 for `false`, 1 for `true`, and no padding bits. `memcmp` on multibyte elements will only be able to fold in cases where enough elements are equal for the answer to be 0. Various tests are added to guard against incorrect folding for cases that miscompile on some system or other prior to this patch. At the same time, the unsigned 32-bit `wchar_t` testing in `test/SemaCXX/constexpr-string.cpp` is restored. Reviewers: rsmith, aaron.ballman, hfinkel Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D55510 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@348938 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Fix ICE when memcpy() is given a pointer to an incomplete arrayPetr Pavlu2018-10-041-0/+3
| | | | | | | | | | | Fix code for constant evaluation of __builtin_memcpy() and __builtin_memmove() that would attempt to divide by zero when given two pointers to an incomplete array. Differential Revision: https://reviews.llvm.org/D51855 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@343761 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix crash on call to __builtin_memcpy with a null pointer to anRichard Smith2018-09-131-0/+4
| | | | | | | | incomplete type. Also improve the diagnostics for similar situations. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@342192 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-08-041-0/+14
| | | | | | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. This reinstates r338455, reverted in r338602, with a fix to avoid trying to constant-evaluate a memcpy call if either pointer operand has an invalid designator. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338941 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r338455 "[constexpr] Support for constant evaluation of ↵Hans Wennborg2018-08-011-14/+0
| | | | | | | | | | | | | | | | __builtin_memcpy and __builtin_memmove (in non-type-punning cases)." It caused asserts during Chromium builds, see reply on the cfe-commits thread. > This is intended to permit libc++ to make std::copy etc constexpr > without sacrificing the optimization that uses memcpy on > trivially-copyable types. > > __builtin_strcpy and __builtin_wcscpy are not handled by this change. > They'd be straightforward to add, but we haven't encountered a need for > them just yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338602 91177308-0d34-0410-b5e6-96231b3b80d8
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-07-311-0/+14
| | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338455 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status