aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-08-10Improve diagnostic for an expression that's not constant because it usesRichard Smith1-1/+14
the address of a constexpr local variable. Suggest adding 'static' to give the constexpr local variable a constant address.
2020-08-07[Fixed Point] Add fixed-point shift operations and consteval.Bevin Hansson1-0/+23
Reviewers: rjmccall, leonardchan, bjope Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D83212
2020-07-22For PR46800, implement the GCC __builtin_complex builtin.Richard Smith1-0/+18
glibc's implementation of the CMPLX macro uses it (with -fgnuc-version set to 4.7 or later).
2020-07-21Reapply "Rename/refactor isIntegerConstantExpression to ↵David Blaikie1-7/+12
getIntegerConstantExpression" Reapply 49e5f603d40083dce9c05796e3cde3a185c3beba which had been reverted in c94332919bd922032e979b3ae3ced5ca5bdf9650. Originally reverted because I hadn't updated it in quite a while when I got around to committing it, so there were a bunch of missing changes to new code since I'd written the patch. Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D76646
2020-07-15Fix "unused variable" warning from recent GCC.Richard Smith1-2/+1
2020-07-13Basic support for flexible array members in constant evaluation.Richard Smith1-1/+11
We don't allow runtime-sized flexible array members, nor initialization of flexible array members, but it seems reasonable to support the most basic case where the flexible array member is empty.
2020-07-12Revert "Rename/refactor isIntegerConstantExpression to ↵David Blaikie1-12/+7
getIntegerConstantExpression" Broke buildbots since I hadn't updated this patch in a while. Sorry for the noise. This reverts commit 49e5f603d40083dce9c05796e3cde3a185c3beba.
2020-07-12Rename/refactor isIntegerConstantExpression to getIntegerConstantExpressionDavid Blaikie1-7/+12
There is a version that just tests (also called isIntegerConstantExpression) & whereas this version is specifically used when the value is of interest (a few call sites were actually refactored to calling the test-only version) so let's make the API look more like it. Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D76646
2020-07-09Fix warning caused by __builtin_expect_with_probability was not handledZhi Zhuang1-0/+1
in places such as constant folding Previously some places that should have handled __builtin_expect_with_probability is missing, so in some case it acts differently than __builtin_expect. For example it was not handled in constant folding, thus in the following program, the "if" condition should be constantly true and folded, but previously it was not handled and cause warning "control may reach end of non-void function" (while __builtin_expect does not): __attribute__((noreturn)) extern void bar(); int foo(int x, int y) { if (y) { if (__builtin_expect_with_probability(1, 1, 1)) bar(); } else return 0; } Now it's fixed. Differential Revisions: https://reviews.llvm.org/D83362
2020-07-08Improve diagnostics for constant evaluation that fails because aRichard Smith1-33/+64
variable's initializer is not known. The hope is that a better diagnostic for this case will reduce the rate at which duplicates of non-bug PR41093 are reported.
2020-06-30[AST] Fix handling of some edge cases in fixed-point division.Bevin Hansson1-0/+4
Division by zero was not being handled, and division of -EPSILON / MAX did not perform rounding correctly.
2020-06-26[AST] Fix certain consteval assignment and comma operator issues with ↵Bevin Hansson1-0/+3
fixed-point types. Summary: Assignment and comma operators for fixed-point types were being constevaled as other binary operators, but they need special treatment. Reviewers: rjmccall, leonardchan, bjope Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73189
2020-06-26[AST] Improve overflow diagnostics for fixed-point constant evaluation.Bevin Hansson1-33/+39
Summary: Diagnostics for overflow were not being produced for fixed-point evaluation. This patch refactors a bit of the evaluator and adds a proper diagnostic for these cases. Reviewers: rjmccall, leonardchan, bjope Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73188
2020-06-26[AST] Add fixed-point division constant evaluation.Bevin Hansson1-0/+9
Reviewers: rjmccall, leonardchan, bjope Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73187
2020-06-26[AST] Add fixed-point multiplication constant evaluation.Bevin Hansson1-0/+9
Reviewers: rjmccall, leonardchan, bjope Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73186
2020-06-26[AST] Add fixed-point subtraction constant evaluation.Bevin Hansson1-1/+10
Reviewers: rjmccall, leonardchan Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D73185
2020-06-25[AST] Fix a crash on accessing a class without definition in constexpr ↵Haojian Wu1-40/+52
function context. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D80981
2020-06-22Implement constexpr BinaryOperator for vector typesErich Keane1-4/+201
These operations do member-wise versions of the all of the listed operations. This patch implements all of the binaryoperators for these types. Note that the test is required to use codegen as I could not come up with a good way to validate the values without the array-subscript operator implemented (which is likely a much more involved change). Differential Reivision: https://reviews.llvm.org/D79755
2020-06-20[AST/Lex/Parse/Sema] As part of using inclusive language withinEric Christopher1-3/+3
the llvm project, migrate away from the use of blacklist and whitelist.
2020-06-15attempt to fix failing buildbots after 3bab88b7baa20b276faaee0aa7ca87f636c91877Tyker1-9/+0
Prevent IR-gen from emitting consteval declarations Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result.
2020-06-15Revert "Prevent IR-gen from emitting consteval declarations"Kirill Bobyrev1-0/+9
This reverts commit 3bab88b7baa20b276faaee0aa7ca87f636c91877. This patch causes test failures: http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/17260
2020-06-15Prevent IR-gen from emitting consteval declarationsTyker1-9/+0
Summary: with this patch instead of emitting calls to consteval function. the IR-gen will emit a store of the already computed result. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76420
2020-06-01[Matrix] Implement matrix index expressions ([][]).Florian Hahn1-0/+1
This patch implements matrix index expressions (matrix[RowIdx][ColumnIdx]). It does so by introducing a new MatrixSubscriptExpr(Base, RowIdx, ColumnIdx). MatrixSubscriptExprs are built in 2 steps in ActOnMatrixSubscriptExpr. First, if the base of a subscript is of matrix type, we create a incomplete MatrixSubscriptExpr(base, idx, nullptr). Second, if the base is an incomplete MatrixSubscriptExpr, we create a complete MatrixSubscriptExpr(base->getBase(), base->getRowIdx(), idx) Similar to vector elements, it is not possible to take the address of a MatrixSubscriptExpr. For CodeGen, a new MatrixElt type is added to LValue, which is very similar to VectorElt. The only difference is that we may need to cast the type of the base from an array to a vector type when accessing it. Reviewers: rjmccall, anemet, Bigcheese, rsmith, martong Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D76791
2020-05-18[OpenCL] Added addrspace_cast operator in C++ mode.Anastasia Stulova1-0/+1
This operator is intended for casting between pointers to objects in different address spaces and follows similar logic as const_cast in C++. Tags: #clang Differential Revision: https://reviews.llvm.org/D60193
2020-05-11[Matrix] Add matrix type to Clang.Florian Hahn1-0/+1
This patch adds a matrix type to Clang as described in the draft specification in clang/docs/MatrixSupport.rst. It introduces a new option -fenable-matrix, which can be used to enable the matrix support. The patch adds new MatrixType and DependentSizedMatrixType types along with the plumbing required. Loads of and stores to pointers to matrix values are lowered to memory operations on 1-D IR arrays. After loading, the loaded values are cast to a vector. This ensures matrix values use the alignment of the element type, instead of LLVM's large vector alignment. The operators and builtins described in the draft spec will will be added in follow-up patches. Reviewers: martong, rsmith, Bigcheese, anemet, dexonsmith, rjmccall, aaron.ballman Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D72281
2020-04-21C++2a -> C++20 in some identifiers; NFC.Aaron Ballman1-10/+10
2020-04-20PR45534: don't ignore unmodeled side-effects when constant-evaluating a call ↵Richard Smith1-1/+1
to __builtin_constant_p. Such side-effects should result in the call evaluating to 'false', even if we can still determine what value the argument expression will evaluate to.
2020-04-17Reland Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+1
I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17Revert "Implement _ExtInt as an extended int type specifier."Sterling Augustine1-1/+0
This reverts commit 61ba1481e200b5b35baa81ffcff81acb678e8508. I'm reverting this because it breaks the lldb build with incomplete switch coverage warnings. I would fix it forward, but am not familiar enough with lldb to determine the correct fix. lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) {
2020-04-17Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+1
Introduction/Motivation: LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax. Integers of non-power-of-two aren't particularly interesting or useful on most hardware, so much so that no language in Clang has been motivated to expose it before. However, in the case of FPGA hardware normal integer types where the full bitwidth isn't used, is extremely wasteful and has severe performance/space concerns. Because of this, Intel has introduced this functionality in the High Level Synthesis compiler[0] under the name "Arbitrary Precision Integer" (ap_int for short). This has been extremely useful and effective for our users, permitting them to optimize their storage and operation space on an architecture where both can be extremely expensive. We are proposing upstreaming a more palatable version of this to the community, in the form of this proposal and accompanying patch. We are proposing the syntax _ExtInt(N). We intend to propose this to the WG14 committee[1], and the underscore-capital seems like the active direction for a WG14 paper's acceptance. An alternative that Richard Smith suggested on the initial review was __int(N), however we believe that is much less acceptable by WG14. We considered _Int, however _Int is used as an identifier in libstdc++ and there is no good way to fall back to an identifier (since _Int(5) is indistinguishable from an unnamed initializer of a template type named _Int). [0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html) [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf Differential Revision: https://reviews.llvm.org/D73967
2020-04-15Improve diagnostic when constant-evaluating a std::initializer_list withRichard Smith1-5/+11
an unexpected form.
2020-04-15Rework how UuidAttr, CXXUuidofExpr, and GUID template arguments and ↵Richard Smith1-3/+21
constants are represented. Summary: Previously, we treated CXXUuidofExpr as quite a special case: it was the only kind of expression that could be a canonical template argument, it could be a constant lvalue base object, and so on. In addition, we represented the UUID value as a string, whose source form we did not preserve faithfully, and that we partially parsed in multiple different places. With this patch, we create an MSGuidDecl object to represent the implicit object of type 'struct _GUID' created by a UuidAttr. Each UuidAttr holds a pointer to its 'struct _GUID' and its original (as-written) UUID string. A non-value-dependent CXXUuidofExpr behaves like a DeclRefExpr denoting that MSGuidDecl object. We cache an APValue representation of the GUID on the MSGuidDecl and use it from constant evaluation where needed. This allows removing a lot of the special-case logic to handle these expressions. Unfortunately, many parts of Clang assume there are only a couple of interesting kinds of ValueDecl, so the total amount of special-case logic is not really reduced very much. This fixes a few bugs and issues: * PR38490: we now support reading from GUID objects returned from __uuidof during constant evaluation. * Our Itanium mangling for a non-instantiation-dependent template argument involving __uuidof no longer depends on which CXXUuidofExpr template argument we happened to see first. * We now predeclare ::_GUID, and permit use of __uuidof without any header inclusion, better matching MSVC's behavior. We do not predefine ::__s_GUID, though; that seems like a step too far. * Our IR representation for GUID constants now uses the correct IR type wherever possible. We will still fall back to using the {i32, i16, i16, [8 x i8]} layout if a definition of struct _GUID is not available. This is not ideal: in principle the two layouts could have different padding. Reviewers: rnk, jdoerfert Subscribers: arphaman, cfe-commits, aeubanks Tags: #clang Differential Revision: https://reviews.llvm.org/D78171
2020-04-07[AST] Fix a crash on invalid constexpr Ctorinitializer when building ↵Haojian Wu1-0/+16
RecoveryExpr. Summary: crash stack: ``` lang: workspace/llvm-project/clang/lib/AST/ExprConstant.cpp:13704: bool EvaluateInPlace(clang::APValue &, (anonymous namespace)::EvalInfo &, const (anonymous namespace)::LValue &, const clang::Expr *, bool): Assertion `!E->isValueDependent()' failed. #8 EvaluateInPlace(clang::APValue&, (anonymous namespace)::EvalInfo&, (anonymous namespace)::LValue const&, clang::Expr const*, bool) workspace/llvm-project/clang/lib/AST/ExprConstant.cpp:0:0 #9 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, clang::APValue*, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) workspace/llvm-project/clang/lib/AST/ExprConstant.cpp:5779:57 #10 HandleConstructorCall(clang::Expr const*, (anonymous namespace)::LValue const&, llvm::ArrayRef<clang::Expr const*>, clang::CXXConstructorDecl const*, (anonymous namespace)::EvalInfo&, clang::APValue&) workspace/llvm-project/clang/lib/AST/ExprConstant.cpp:5819:10 #11 clang::Expr::isPotentialConstantExpr(clang::FunctionDecl const*, llvm::SmallVectorImpl<std::pair<clang::SourceLocation, clang::PartialDiagnostic> >&) workspace/llvm-project/clang/lib/AST/ExprConstant.cpp:14746:5 #12 CheckConstexprFunctionBody(clang::Sema&, clang::FunctionDecl const*, clang::Stmt*, clang::Sema::CheckConstexprKind) workspace/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:2306:7 #13 clang::Sema::CheckConstexprFunctionDefinition(clang::FunctionDecl const*, clang::Sema::CheckConstexprKind) workspace/llvm-project/clang/lib/Sema/SemaDeclCXX.cpp:1766:0 #14 clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) workspace/llvm-project/clang/lib/Sema/SemaDecl.cpp:14357:9 #15 clang::Parser::ParseFunctionStatementBody(clang::Decl*, clang::Parser::ParseScope&) workspace/llvm-project/clang/lib/Parse/ParseStmt.cpp:2213:18 ``` Reviewers: sammccall Reviewed By: sammccall Subscribers: rsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77041
2020-04-06Remove llvm::Error include form Diagnostic.hReid Kleckner1-0/+1
Saves ~400 related LLVM ADT. llvm/ADT/Error.h takes 90ms to parse. $ diff -u <(sort thedeps-before.txt) <(sort thedeps-after.txt) \ | grep '^[-+] ' | sort | uniq -c | sort -nr 403 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Error.h 403 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm-c/Error.h 397 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Format.h 397 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Debug.h 377 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/StringExtras.h 158 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm-c/ExternC.h 138 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/ErrorOr.h 13 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/raw_ostream.h 13 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/SmallString.h 5 - /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/ADT/Twine.h
2020-04-05Permit constant evaluation of mixed __builtin_memcmp between char andRichard Smith1-4/+9
char8_t.
2020-04-05Add documentation and testing forRichard Smith1-1/+1
2c88a485c71155c19e512f22c54e63ee337282a3. Also extend it to cover memchr for consistency.
2020-04-05[clang] Make libcxx test suite pass again after memcmp changesDavid Zarzycki1-3/+5
2020-04-03PR45402: Make the restrictions on constant evaluation of memcmp andRichard Smith1-53/+17
memchr consistent and comprehensible, and document them. We previously allowed evaluation of memcmp on arrays of integers of any size, so long as the call evaluated to 0, and allowed evaluation of memchr on any array of integral type of size 1 (including enums). The purpose of constant-evaluating these builtins is only to support constexpr std::char_traits, so we now consistently allow them on arrays of (possibly signed or unsigned) char only.
2020-04-02[OPENMP50]Add initial support for OpenMP 5.0 iterator.Alexey Bataev1-0/+1
Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-04-01Revert "[OPENMP50]Add initial support for OpenMP 5.0 iterator."Alexey Bataev1-1/+0
This reverts commit f08df464ae89972a777c0a7e299a2c153a9829d8 to fix the bug with serialization support for iterator expression.
2020-04-01[OPENMP50]Add initial support for OpenMP 5.0 iterator.Alexey Bataev1-0/+1
Added basic parsing/semantic analysis/(de)serialization support for iterator expression introduced in OpenMP 5.0.
2020-03-30[OPENMP50]Add basic support for array-shaping operation.Alexey Bataev1-0/+1
Summary: Added basic representation and parsing/sema handling of array-shaping operations. Array shaping expression is an expression of form ([s0]..[sn])base, where s0, ..., sn must be a positive integer, base - a pointer. This expression is a kind of cast operation that converts pointer expression into an array-like kind of expression. Reviewers: rjmccall, rsmith, jdoerfert Subscribers: guansong, arphaman, cfe-commits, caomhin, kkwli0 Tags: #clang Differential Revision: https://reviews.llvm.org/D74144
2020-03-29PR45350: Handle unsized array CXXConstructExprs in constant evaluationRichard Smith1-1/+22
of array new expressions with runtime bound.
2020-03-24[AST] Add RecoveryExpr to retain expressions on semantic errorsHaojian Wu1-0/+1
Normally clang avoids creating expressions when it encounters semantic errors, even if the parser knows which expression to produce. This works well for the compiler. However, this is not ideal for source-level tools that have to deal with broken code, e.g. clangd is not able to provide navigation features even for names that compiler knows how to resolve. The new RecoveryExpr aims to capture the minimal set of information useful for the tools that need to deal with incorrect code: source range of the expression being dropped, subexpressions of the expression. We aim to make constructing RecoveryExprs as simple as possible to ensure writing code to avoid dropping expressions is easy. Producing RecoveryExprs can result in new code paths being taken in the frontend. In particular, clang can produce some new diagnostics now and we aim to suppress bogus ones based on Expr::containsErrors. We deliberately produce RecoveryExprs only in the parser for now to minimize the code affected by this patch. Producing RecoveryExprs in Sema potentially allows to preserve more information (e.g. type of an expression), but also results in more code being affected. E.g. SFINAE checks will have to take presence of RecoveryExprs into account. Initial implementation only works in C++ mode, as it relies on compiler postponing diagnostics on dependent expressions. C and ObjC often do not do this, so they require more work to make sure we do not produce too many bogus diagnostics on the new expressions. See documentation of RecoveryExpr for more details. original patch from Ilya This change is based on https://reviews.llvm.org/D61722 Reviewers: sammccall, rsmith Reviewed By: sammccall, rsmith Tags: #clang Differential Revision: https://reviews.llvm.org/D69330
2020-03-20Use values cached in ConstantExprs for expression evaluation whereWyatt Childers1-2/+7
present. No functionality change intended. Differential Revision: https://reviews.llvm.org/D76438
2020-03-17PR45133: Don't crash if the active member of a union changes while it'sRichard Smith1-4/+31
in the process of being initialized.
2020-03-12Fix unused variable warning. NFCI.Simon Pilgrim1-0/+1
2020-03-03PR45087: Fix check for emptiness when determining whether a trivial copyRichard Smith1-21/+14
operation needs to read from its operand.
2020-02-18P0593R6: Pseudo-destructor expressions end object lifetimes.Richard Smith1-7/+31
This only has an observable effect on constant evaluation.
2020-02-18PR44958: Allow member calls and typeid / dynamic_cast on mutable objectsRichard Smith1-0/+7
and objects with mutable subobjects. The standard wording doesn't really cover these cases; accepting all such cases seems most in line with what we do in other cases and what other compilers do. (Essentially this means we're assuming that objects external to the evaluation are always in-lifetime.)
generated by cgit v1.1 at 2025-10-06 00:47:40 +0000