aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15[PowerPC] Enable paired vector type and intrinsics when MMA is disabledBaptiste Saleil1-1/+1
This patch enables the Clang type __vector_pair and its associated LLVM intrinsics even when MMA is disabled. With this patch, the type is now controlled by the PPC paired-vector-memops option. The builtins and intrinsics will be renamed to drop the mma prefix in another patch. Differential Revision: https://reviews.llvm.org/D91819
2020-12-10[AST] Fix a constexpr-evaluator crash on error-dependent returnstmt.Haojian Wu1-2/+5
When the evaluator encounters an error-dependent returnstmt, before this patch it returned a ESR_Returned without setting the result, the callsides think this is a successful execution, and try to access the Result which causes the crash. The fix is to always return failed as we don't know the result of the error-dependent return stmt. Differential Revision: https://reviews.llvm.org/D92969
2020-11-18[AST] Enhance the const expression evaluator to support error-dependent exprs.Haojian Wu1-48/+107
Fix a crash when evaluating a constexpr function which contains recovery-exprs. https://bugs.llvm.org/show_bug.cgi?id=46837 Would be nice to have constant expression evaluator support general template value-dependent expressions, but it requires more work. This patch is a good start I think, to handle the error-only value-dependent expressions. Differential Revision: https://reviews.llvm.org/D84637
2020-11-10Move code to determine the type of an LValueBase out of ExprConstant andRichard Smith1-42/+1
into a member function on LValueBase. NFC.
2020-10-28[Clang][PowerPC] Add __vector_pair and __vector_quad typesBaptiste Saleil1-0/+3
Define the __vector_pair and __vector_quad types that are used to manipulate the new accumulator registers introduced by MMA on PowerPC. Because these two types are specific to PowerPC, they are defined in a separate new file so it will be easier to add other PowerPC specific types if we need to in the future. Differential Revision: https://reviews.llvm.org/D81508
2020-10-26Fix checking for C++98 ICEs in C++11-and-later mode to not consider useRichard Smith1-1/+5
of a reference to be acceptable.
2020-10-26Revert "Revert "Ensure that checkInitIsICE is called exactly once for every ↵Zequan Wu1-6/+6
variable"" This reverts commit a2ac64dd905422ed84e273a98d846df022a5e2ec.
2020-10-26Revert "Ensure that checkInitIsICE is called exactly once for every variable"Zequan Wu1-6/+6
This causing `Assertion Result && "Could not evaluate expression"' failed` at https://bugs.chromium.org/p/chromium/issues/detail?id=1142009 This reverts commit 76c0092665867a6defcd328ba0d0d976eb65d991.
2020-10-26Unconfuse gcc5.3 after 2e204e23911b1f / D87528Nico Weber1-3/+3
The local variable CmpResult added in that change shadowed the type CmpResult, which confused an older gcc. Rename the variable CmpResult to APFloatCmpResult.
2020-10-25[clang] Enable support for #pragma STDC FENV_ACCESSMelanie Blower1-9/+45
Reviewers: rjmccall, rsmith, sepavloff Differential Revision: https://reviews.llvm.org/D87528
2020-10-24For P0732R2, P1907R1: ensure that template parameter objects don't referRichard Smith1-99/+177
to disallowed objects or have non-constant destruction.
2020-10-23PR47954 / DR2126: permit temporary objects that are lifetime-extended byRichard Smith1-9/+14
variables that are usable in constant expressions to themselves be usable in constant expressions.
2020-10-23Fix typo in diagnostic name.Richard Smith1-1/+1
No functionality change intended.
2020-10-22Fix constant evaluation of zero-initialization of a union whose firstRichard Smith1-0/+2
FieldDecl is an unamed bitfield. Unnamed bitfields aren't non-static data member, so such a bitfield isn't actually the first non-static data member.
2020-10-21Ensure that the "value" of an unnamed bit-field isn't taken intoRichard Smith1-1/+1
account when determining the identity of a class NTTP.
2020-10-21Add more test coverage for APValue serialization / deserialization andRichard Smith1-1/+1
fix a few exposed bugs.
2020-10-21[c++20] For P0732R2 / P1907R1: Basic frontend support for class types asRichard Smith1-6/+17
non-type template parameters. Create a unique TemplateParamObjectDecl instance for each such value, representing the globally unique template parameter object to which the template parameter refers. No IR generation support yet; that will follow in a separate patch.
2020-10-20Don't permit array bound constant folding in OpenCL.Richard Smith1-17/+16
Permitting non-standards-driven "do the best you can" constant-folding of array bounds is permitted solely as a GNU compatibility feature. We should not be doing it in any language mode that is attempting to be conforming. From https://reviews.llvm.org/D20090 it appears the intent here was to permit `__constant int` globals to be used in array bounds, but the change in that patch only added half of the functionality necessary to support that in the constant evaluator. This patch adds the other half of the functionality and turns off constant folding for array bounds in OpenCL. I couldn't find any spec justification for accepting the kinds of cases that D20090 accepts, so a reference to where in the OpenCL specification this is permitted would be useful. Note that this change also affects the code generation in one test: because after 'const int n = 0' we now treat 'n' as a constant expression with value 0, it's now a null pointer, so '(local int *)n' forms a null pointer rather than a zero pointer. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D89520
2020-10-19Properly track whether a variable is constant-initialized.Richard Smith1-10/+9
This fixes miscomputation of __builtin_constant_evaluated in the initializer of a variable that's not usable in constant expressions, but is readable when constant-folding. If evaluation of a constant initializer fails, we throw away the evaluated result instead of keeping it as a non-constant-initializer value for the variable, because it might not be a correct value. To avoid regressions for initializers that are foldable but not formally constant initializers, we now try constant-evaluating some globals in C++ twice: once to check for a constant initializer (in an mode where is_constannt_evaluated returns true) and again to determine the runtime value if the initializer is not a constant initializer.
2020-10-19Refactor tracking of constant initializers for variables.Richard Smith1-5/+9
Instead of framing the interface around whether the variable is an ICE (which is only interesting in C++98), primarily track whether the initializer is a constant initializer (which is interesting in all C++ language modes). No functionality change intended.
2020-10-19Ensure that checkInitIsICE is called exactly once for every variableRichard Smith1-31/+19
for which it matters. This is a step towards separating checking for a constant initializer (in which std::is_constant_evaluated returns true) and any other evaluation of a variable initializer (in which it returns false).
2020-10-16Treat constant contexts as being in the default rounding mode.Richard Smith1-0/+5
This addresses a regression where pretty much all C++ compilations using -frounding-math now fail, due to rounding being performed in constexpr function definitions in the standard library. This follows the "manifestly constant evaluated" approach described in https://reviews.llvm.org/D87528#2270676 -- evaluations that are required to succeed at compile time are permitted even in regions with dynamic rounding modes, as are (unfortunately) the evaluation of the initializers of local variables of const integral types. Differential Revision: https://reviews.llvm.org/D89360
2020-10-16Remove dead variable to silence compiler warning [NFC]Mikael Holmen1-2/+0
2020-10-14PR47805: Use a single object for a function parameter in the caller andRichard Smith1-155/+323
callee in constant evaluation. We previously made a deep copy of function parameters of class type when passing them, resulting in the destructor for the parameter applying to the original argument value, ignoring any modifications made in the function body. This also meant that the 'this' pointer of the function parameter could be observed changing between the caller and the callee. This change completely reimplements how we model function parameters during constant evaluation. We now model them roughly as if they were variables living in the caller, albeit with an artificially reduced scope that covers only the duration of the function call, instead of modeling them as temporaries in the caller that we partially "reparent" into the callee at the point of the call. This brings some minor diagnostic improvements, as well as significantly reduced stack usage during constant evaluation.
2020-10-13Revert "PR47805: Use a single object for a function parameter in the caller and"Richard Smith1-322/+155
Breaks a clangd unit test. This reverts commit 8f8b9f2cca0b73314342c721186ae9c860ca273c.
2020-10-13PR47805: Use a single object for a function parameter in the caller andRichard Smith1-155/+322
callee in constant evaluation. We previously made a deep copy of function parameters of class type when passing them, resulting in the destructor for the parameter applying to the original argument value, ignoring any modifications made in the function body. This also meant that the 'this' pointer of the function parameter could be observed changing between the caller and the callee. This change completely reimplements how we model function parameters during constant evaluation. We now model them roughly as if they were variables living in the caller, albeit with an artificially reduced scope that covers only the duration of the function call, instead of modeling them as temporaries in the caller that we partially "reparent" into the callee at the point of the call. This brings some minor diagnostic improvements, as well as significantly reduced stack usage during constant evaluation.
2020-10-13Revert "PR47805: Use a single object for a function parameter in the caller and"Richard Smith1-316/+152
The buildbots are displeased. This reverts commit 8d03a972ce8e92815ffe3d5d86aa027605ed92e2.
2020-10-13PR47805: Use a single object for a function parameter in the caller andRichard Smith1-152/+316
callee in constant evaluation. We previously made a deep copy of function parameters of class type when passing them, resulting in the destructor for the parameter applying to the original argument value, ignoring any modifications made in the function body. This also meant that the 'this' pointer of the function parameter could be observed changing between the caller and the callee. This change completely reimplements how we model function parameters during constant evaluation. We now model them roughly as if they were variables living in the caller, albeit with an artificially reduced scope that covers only the duration of the function call, instead of modeling them as temporaries in the caller that we partially "reparent" into the callee at the point of the call. This brings some minor diagnostic improvements, as well as significantly reduced stack usage during constant evaluation.
2020-10-13[Fixed Point] Add fixed-point to floating point cast types and consteval.Bevin Hansson1-0/+33
Reviewed By: leonardchan Differential Revision: https://reviews.llvm.org/D86631
2020-10-12Canonicalize declaration pointers when forming APValues.Richard Smith1-12/+6
References to different declarations of the same entity aren't different values, so shouldn't have different representations. Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb, most recently reverted in 9a33f027ac7d73e14ae287e78ab554142d1cbc8f due to a bug caused by ObjCInterfaceDecls not propagating availability attributes along their redeclaration chains; that bug was fixed in e2d4174e9c66251d1b408234b53f53d0903c0285.
2020-10-12Revert "Canonicalize declaration pointers when forming APValues."Arthur Eubanks1-6/+12
This reverts commit 9dcd96f728863d40d6f5922ed52732fdd728fb5f. See https://crbug.com/1134762.
2020-10-06[c++17] Implement P0145R3 during constant evaluation.Richard Smith1-43/+70
Ensure that we evaluate assignment and compound-assignment right-to-left, and array subscripting left-to-right. Fixes PR47724. This is a re-commit of ded79be, reverted in 37c74df, with a fix and test for the crasher bug previously introduced.
2020-10-06Revert "[c++17] Implement P0145R3 during constant evaluation."Dmitri Gribenko1-59/+36
This reverts commit ded79be63555f4e5bfdb0db27ef22b71fe568474. It causes a crash (I sent the crash reproducer directly to the author).
2020-10-05[c++17] Implement P0145R3 during constant evaluation.Richard Smith1-36/+59
Ensure that we evaluate assignment and compound-assignment right-to-left, and array subscripting left-to-right. Fixes PR47724.
2020-10-01[AST] do not error on APFloat invalidOp in default modeSanjay Patel1-1/+2
If FP exceptions are ignored, we should not error out of compilation just because APFloat indicated an exception. This is required as a preliminary step for D88238 which changes APFloat behavior for signaling NaN convert() to set the opInvalidOp exception status. Currently, there is no way to trigger this error because convert() never sets opInvalidOp. FP binops that set opInvalidOp also create a NaN, so the path to checkFloatingPointResult() is blocked by a different diagnostic: // [expr.pre]p4: // If during the evaluation of an expression, the result is not // mathematically defined [...], the behavior is undefined. // FIXME: C++ rules require us to not conform to IEEE 754 here. if (LHS.isNaN()) { Info.CCEDiag(E, diag::note_constexpr_float_arithmetic) << LHS.isNaN(); return Info.noteUndefinedBehavior(); } return checkFloatingPointResult(Info, E, St); Differential Revision: https://reviews.llvm.org/D88664
2020-09-30Fix interaction of `constinit` and `weak`.Richard Smith1-1/+1
We previously took a shortcut and said that weak variables never have constant initializers (because those initializers are never correct to use outside the variable). We now say that weak variables can have constant initializers, but are never usable in constant expressions.
2020-09-27Canonicalize declaration pointers when forming APValues.Richard Smith1-12/+6
References to different declarations of the same entity aren't different values, so shouldn't have different representations. Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb with fixed handling for weak declarations. We now look for attributes on the most recent declaration when determining whether a declaration is weak. (Second recommit with further fixes for mishandling of weak declarations. Our behavior here is fundamentally unsound -- see PR47663 -- but this approach attempts to not make things worse.)
2020-09-26[FPEnv] Evaluate constant expressions under non-default rounding modesSerge Pavlov1-15/+67
The change implements evaluation of constant floating point expressions under non-default rounding modes. The main objective was to support evaluation of global variable initializers, where constant rounding mode may be specified by `#pragma STDC FENV_ROUND`. Differential Revision: https://reviews.llvm.org/D87822
2020-09-22Revert "Canonicalize declaration pointers when forming APValues."Leonard Chan1-6/+12
This reverts commit 905b9ca26c94fa86339451a528cedde5004fc1bb. Reverting because this strips `weak` attributes off function declarations, leading to the linker error we see at https://ci.chromium.org/p/fuchsia/builders/ci/clang_toolchain.fuchsia-arm64-debug-subbuild/b8868932035091473008. See https://reviews.llvm.org/rG905b9ca26c94 for reproducer details.
2020-09-16Canonicalize declaration pointers when forming APValues.Richard Smith1-12/+6
References to different declarations of the same entity aren't different values, so shouldn't have different representations. Recommit of e6393ee813178e9d3306b8e3c6949a4f32f8a2cb with fixed handling for weak declarations. We now look for attributes on the most recent declaration when determining whether a declaration is weak.
2020-09-04Revert "Canonicalize declaration pointers when forming APValues."Nico Weber1-6/+12
This reverts commit e6393ee813178e9d3306b8e3c6949a4f32f8a2cb. It breaks Wunreachable for weak attributes, see http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20200831/336645.html
2020-09-03Canonicalize declaration pointers when forming APValues.Richard Smith1-12/+6
References to different declarations of the same entity aren't different values, so shouldn't have different representations.
2020-09-02[AST] Fix handling of long double and bool in __builtin_bit_castErik Pilkington1-3/+39
On x86, long double has 6 unused trailing bytes. This patch changes the constant evaluator to treat them as though they were padding bytes, so reading from them results in an indeterminate value, and nothing is written for them. Also, fix a similar bug with bool, but instead of treating the unused bits as padding, enforce that they're zero. Differential revision: https://reviews.llvm.org/D76323
2020-08-23[X86] Enable constexpr on ROTL/ROTR intrinsics (PR31446)Simon Pilgrim1-2/+12
This enables constexpr rotate intrinsics defined in ia32intrin.h, including the MS specific builtins.
2020-08-22Enable constexpr on BITREVERSE builtin intrinsics (PR47249)Simon Pilgrim1-0/+11
This enables us to use the __builtin_bitreverse 8/16/32/64 intrinsics inside constexpr code. Differential Revision: https://reviews.llvm.org/D86339
2020-08-22Enable constexpr on ROTATELEFT/ROTATERIGHT builtin intrinsics (PR47249)Simon Pilgrim1-0/+24
This enables us to use the __builtin_rotateleft / __builtin_rotateright 8/16/32/64 intrinsics inside constexpr code. Differential Revision: https://reviews.llvm.org/D86342
2020-08-20Don't reject uses of void-returning consteval functions.Richard Smith1-0/+4
2020-08-20[ADT] Move FixedPoint.h from Clang to LLVM.Bevin Hansson1-1/+3
This patch moves FixedPointSemantics and APFixedPoint from Clang to LLVM ADT. This will make it easier to use the fixed-point classes in LLVM for constructing an IR builder for fixed-point and for reusing the APFixedPoint class for constant evaluation purposes. RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-August/144025.html Reviewed By: leonardchan, rjmccall Differential Revision: https://reviews.llvm.org/D85312
2020-08-17[NFC] Tweak a comment about the lock-free builtinsLuís Marques1-2/+2
2020-08-12PR47143: Don't crash while constant-evaluating value-initialization ofRichard Smith1-4/+14
an array of unknown bound as the initializer of an array new expression.
generated by cgit v1.1 at 2025-10-05 22:44:49 +0000