aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2018-04-10[ExprConstant] Use an AST node and a version number as a key to createAkira Hatanaka1-58/+128
an APValue and retrieve it from map Temporaries. The version number is needed when a single AST node is visited multiple times and is used to create APValues that are required to be distinct from each other (for example, MaterializeTemporaryExprs in default arguments and VarDecls in loops). rdar://problem/36505742 Differential Revision: https://reviews.llvm.org/D42776 llvm-svn: 329671
2018-04-05Disable -fmerge-all-constants as default.Manoj Gupta1-3/+0
Summary: "-fmerge-all-constants" is a non-conforming optimization and should not be the default. It is also causing miscompiles when building Linux Kernel (https://lkml.org/lkml/2018/3/20/872). Fixes PR18538. Reviewers: rjmccall, rsmith, chandlerc Reviewed By: rsmith, chandlerc Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D45289 llvm-svn: 329300
2018-04-05[AST] Don't track lambda captures when checking a potential constant expression.Erik Pilkington1-6/+19
Fixes PR36054. Differential revision: https://reviews.llvm.org/D45194 llvm-svn: 329244
2018-03-13Reland "[Attr] Fix parameter indexing for several attributes"Joel E. Denny1-6/+4
Relands r326602 (reverted in r326862) with new test and fix for PR36620. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 327405
2018-03-09PR36645: Go looking for an appropriate array bound when constant-evaluating aRichard Smith1-4/+12
name of an array object. llvm-svn: 327099
2018-03-07Reland r326766 (with a slightly modified test)George Burgess IV1-1/+5
The original revert was done in r326869, since reverting r326602 broke the test added by this. The new test should be less dependent on r326602. llvm-svn: 326872
2018-03-07Revert 326766 too, after r326862 the test fails and I don't know how to fix.Nico Weber1-5/+1
llvm-svn: 326869
2018-03-07Revert r326602, it caused PR36620.Nico Weber1-4/+6
llvm-svn: 326862
2018-03-06[ExprConstant] Look through ExprWithCleanups for `allocsize`George Burgess IV1-1/+5
llvm-svn: 326766
2018-03-02[Attr] Fix parameter indexing for several attributesJoel E. Denny1-6/+4
The patch fixes a number of bugs related to parameter indexing in attributes: * Parameter indices in some attributes (argument_with_type_tag, pointer_with_type_tag, nonnull, ownership_takes, ownership_holds, and ownership_returns) are specified in source as one-origin including any C++ implicit this parameter, were stored as zero-origin excluding any this parameter, and were erroneously printing (-ast-print) and confusingly dumping (-ast-dump) as the stored values. * For alloc_size, the C++ implicit this parameter was not subtracted correctly in Sema, leading to assert failures or to silent failures of __builtin_object_size to compute a value. * For argument_with_type_tag, pointer_with_type_tag, and ownership_returns, the C++ implicit this parameter was not added back to parameter indices in some diagnostics. This patch fixes the above bugs and aims to prevent similar bugs in the future by introducing careful mechanisms for handling parameter indices in attributes. ParamIdx stores a parameter index and is designed to hide the stored encoding while providing accessors that require each use (such as printing) to make explicit the encoding that is needed. Attribute declarations declare parameter index arguments as [Variadic]ParamIdxArgument, which are exposed as ParamIdx[*]. This patch rewrites all attribute arguments that are processed by checkFunctionOrMethodParameterIndex in SemaDeclAttr.cpp to be declared as [Variadic]ParamIdxArgument. The only exception is xray_log_args's argument, which is encoded as a count not an index. Differential Revision: https://reviews.llvm.org/D43248 llvm-svn: 326602
2018-03-01Remove redundant casts. NFCGeorge Burgess IV1-1/+1
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
2018-02-23[ExprConstant] Fix crash when initialize an indirect field with another field.Volodymyr Sapsai1-4/+16
When indirect field is initialized with another field, you have MemberExpr with CXXThisExpr that corresponds to the field's immediate anonymous parent. But 'this' was referring to the non-anonymous parent. So when we were building LValue Designator, it was incorrect as it had wrong starting point. Usage of such designator would cause unexpected APValue changes and crashes. The fix is in adjusting 'this' for indirect fields from non-anonymous parent to the field's immediate parent. Discovered by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4985 rdar://problem/36359187 Reviewers: rsmith, efriedma Reviewed By: rsmith Subscribers: cfe-commits, jkorous-apple Differential Revision: https://reviews.llvm.org/D42498 llvm-svn: 325997
2018-02-21In C++14 onwards, it is permitted to read mutable members in constantRichard Smith1-10/+22
expressions, if their lifetime began during the evaluation of the expression. This is technically not allowed in C++11, though we could consider permitting it there too, as an extension. llvm-svn: 325663
2018-02-14[AST] Refine the condition for element-dependent array fillersIvan A. Kosarev1-2/+23
This patch fixes clang to not consider braced initializers for aggregate elements of arrays to be potentially dependent on the indices of the initialized elements. Resolves bug 18978: initialize a large static array = clang oom? https://bugs.llvm.org/show_bug.cgi?id=18978 Differential Revision: https://reviews.llvm.org/D43187 llvm-svn: 325120
2018-01-09Track in the AST whether the operand to a UnaryOperator can overflow and ↵Aaron Ballman1-48/+41
then use that logic when evaluating constant expressions and emitting codegen. llvm-svn: 322074
2018-01-06Add support for a limited subset of TS 18661-3 math builtins.Benjamin Kramer1-2/+8
These just overloads for _Float128. They're supported by GCC 7 and used by glibc. APFloat support is already there so just add the overloads. __builtin_copysignf128 __builtin_fabsf128 __builtin_huge_valf128 __builtin_inff128 __builtin_nanf128 __builtin_nansf128 This is the same support that GCC has, according to the documentation, but limited to _Float128. llvm-svn: 321948
2017-12-20Fix an assertion failure regression in isDesignatorAtObjectEnd forAlex Lorenz1-1/+4
__builtin_object_size with incomplete array type in struct The commit r316245 introduced a regression that causes an assertion failure when Clang tries to cast an IncompleteArrayType to a PointerType when evaluating __builtin_object_size. rdar://36094951 Differential Revision: https://reviews.llvm.org/D41405 llvm-svn: 321222
2017-12-19Silence a bunch of implicit fallthrough warningsAdrian Prantl1-5/+6
llvm-svn: 321115
2017-12-14[c++20] P0515R3: Parsing support and basic AST construction for operator <=>.Richard Smith1-0/+1
Adding the new enumerator forced a bunch more changes into this patch than I would have liked. The -Wtautological-compare warning was extended to properly check the new comparison operator, clang-format needed updating because it uses precedence levels as weights for determining where to break lines (and several operators increased their precedence levels with this change), thread-safety analysis needed changes to build its own IL properly for the new operator. All "real" semantic checking for this operator has been deferred to a future patch. For now, we use the relational comparison rules and arbitrarily give the builtin form of the operator a return type of 'void'. llvm-svn: 320707
2017-11-15PR35214: don't crash if we see an array of unknown bound added to an empty ↵Richard Smith1-4/+5
but invalid designator. llvm-svn: 318258
2017-10-24Unnamed bitfields don't block constant evaluation of constexpr ctorsJordan Rose1-0/+3
C++14 [dcl.constexpr]p4 states that in the body of a constexpr constructor, > every non-variant non-static data member and base class sub-object shall be initialized However, [class.bit]p2 notes that > Unnamed bit-fields are not members and cannot be initialized. Therefore, we should make sure to filter them out of the check that all fields are initialized. Fixing this makes the constant evaluator a bit smarter, and specifically allows constexpr constructors to avoid tripping -Wglobal-constructors when the type contains unnamed bitfields. Reviewed at https://reviews.llvm.org/D39035. llvm-svn: 316408
2017-10-20Implement current CWG direction for support of arrays of unknown bounds inRichard Smith1-27/+66
constant expressions. We permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). This is based on r311970 and r301822 (the former by me and the latter by Robert Haberlach). Between then and now, two things have changed: we have committee feedback indicating that this is indeed the right direction, and the code broken by this change has been fixed. This is necessary in C++17 to continue accepting certain forms of non-type template argument involving arrays of unknown bound. llvm-svn: 316245
2017-10-17[OpenMP] Implement omp_is_initial_device() as builtinJonas Hahnfeld1-0/+3
This allows to return the static value that we know at compile time. Differential Revision: https://reviews.llvm.org/D38968 llvm-svn: 316001
2017-10-04[ExprConstant] Allow constexpr ctor to modify non static data membersErik Pilkington1-3/+30
Fixes PR19741. Differential revision: https://reviews.llvm.org/D38483 llvm-svn: 314865
2017-08-30Revert "Improve constant expression evaluation of arrays of unknown bound."Martin Bohme1-59/+26
This reverts commit r311970. Breaks internal tests. llvm-svn: 312108
2017-08-29Improve constant expression evaluation of arrays of unknown bound.Richard Smith1-26/+59
The standard is not clear on how these are supposed to be handled, so we conservatively treat as non-constant any cases whose value is unknown or whose evaluation might result in undefined behavior. llvm-svn: 311970
2017-08-17PR34161: support evaluation of 'void()' expressions in C++14 onwards.Richard Smith1-0/+2
llvm-svn: 311115
2017-08-17Fix undefined behavior that is caused by not always initializing a bool.Daniel Jasper1-0/+1
The fix in r310994 is incomplete, as moveFromAndCancel can set the pointer without initializing OldIsSpeculativelyEvaluating. llvm-svn: 311070
2017-08-16Fix a UBSan failure where this boolean was copied when uninitialized.Chandler Carruth1-1/+1
When r310905 moved the pointer and bool out of a PointerIntPair, it made them end up uninitialized and caused UBSan failures when copying the uninitialized boolean. However, making the pointer be null should avoid the reference to the boolean entirely. llvm-svn: 310994
2017-08-15Avoid PointerIntPair of constexpr EvalInfo structsReid Kleckner1-13/+11
They are stack allocated, so their alignment is not to be trusted. 32-bit MSVC only guarantees 4 byte stack alignment, even though alignof would tell you otherwise. I tried fixing this with __declspec align, but that apparently upsets GCC. Hopefully this version will satisfy all compilers. See PR32018 for some info about the mingw issues. Should supercede https://reviews.llvm.org/D34873 llvm-svn: 310905
2017-07-07[MS] Don't statically initialize dllimport member function pointersReid Kleckner1-0/+16
Summary: r306137 made dllimport pointers to member functions non-constant. This is correct because a load must be executed to resolve any dllimported data. However, r306137 did not account for the use of dllimport member function pointers used as template arguments. This change re-lands r306137 with a template instantiation fix. This fixes PR33570. Reviewers: rnk, majnemer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34714 llvm-svn: 307446
2017-07-05fix trivial typos in comments; NFCHiroshi Inoue1-2/+2
llvm-svn: 307123
2017-06-26Revert r301742, which caused us to try to evaluate all full-expressions.Richard Smith1-9/+4
Also add testcases for a bunch of expression forms that cause our evaluator to crash. See PR33140 and PR32864 for crashes that this was causing. This reverts r305287, which reverted r305239, which reverted r301742. The previous revert claimed that buildbots were broken, but did not add any testcases and the buildbots have lost all memory of what was wrong here. Changes to test/OpenMP are not reverted; another change has triggered those tests to change their output in the same way that r301742 did. llvm-svn: 306346
2017-06-23Revert "[MS] Don't statically initialize dllimport member function pointers"Reid Kleckner1-16/+0
This reverts commit r306137. It has problems on code like this: struct __declspec(dllimport) Foo { int a; int get_a() { return a; } }; template <int (Foo::*Getter)()> struct HasValue { int operator()(Foo *p) { return (p->*Getter)(); } }; int main() { Foo f; f.a = 3; int x = HasValue<&Foo::get_a>()(&f); } llvm-svn: 306175
2017-06-23[MS] Don't statically initialize dllimport member function pointersReid Kleckner1-0/+16
We were already applying the same rules to dllimport function pointers. David Majnemer added that logic back in r211677 to fix PR20130. We failed to extend that logic to non-virtual member function pointers, which are basically function pointers in a struct with some extra offsets. Fixes PR33570. llvm-svn: 306137
2017-06-13Revert "Revert r301742 which made ExprConstant checking apply to all ↵Diana Picus1-4/+9
full-exprs." This reverts commit r305239 because it broke the buildbots (the diag-flags.cpp test is failing). llvm-svn: 305287
2017-06-12Revert r301742 which made ExprConstant checking apply to all full-exprs.Nick Lewycky1-9/+4
This patch also exposed pre-existing bugs in clang, see PR32864 and PR33140#c3 . llvm-svn: 305239
2017-06-12Revert r303316, a change to ExprConstant to evaluate function arguments.Nick Lewycky1-28/+5
The patch was itself correct but it uncovered other bugs which are going to be difficult to fix, per PR33140. llvm-svn: 305233
2017-06-03Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+3
llvm-svn: 304650
2017-05-26Create valid LValue to represent null pointers in constant exprsTim Northover1-6/+14
We were leaving the SubobjectDesignator in a surprising situation, where it was allegedly valid but didn't actually refer to a type. This caused a crash later on. This patch fills out the SubobjectDesignator with the pointee type (as happens in other evaluations of constant pointers) so that we don't crash later. llvm-svn: 303957
2017-05-17The constant expression evaluator should examine function arguments for ↵Nick Lewycky1-5/+28
non-constexpr function calls unless the EvalInfo says to stop. llvm-svn: 303317
2017-05-02Revert r301822 (and dependent r301825), which tried to improve theDaniel Jasper1-136/+106
handling of constexprs with unknown bounds. This triggers a corner case of the language where it's not yet clear whether this should be an error: struct A { static void *const a[]; static void *const b[]; }; constexpr void *A::a[] = {&b[0]}; constexpr void *A::b[] = {&a[0]}; When discovering the initializer for A::a, the bounds of A::b aren't known yet. It is unclear whether warning about errors should be deferred until the end of the translation unit, possibly resolving errors that can be resolved. In practice, the compiler can know the bounds of all arrays in this example. Credits for reproducers and explanation go to Richard Smith. Richard, please add more info in case my explanation is wrong. llvm-svn: 301963
2017-05-02Revert r301785 (and r301787) because they caused PR32864.Nick Lewycky1-7/+1
The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form. llvm-svn: 301891
2017-05-01Silence unused variable warning. NFC.Benjamin Kramer1-1/+1
llvm-svn: 301825
2017-05-01Improve handling of arrays of unknown bound in constant expressions.Richard Smith1-106/+136
Do not spuriously reject constexpr functions that access elements of an array of unknown bound; this may later become valid once the bound is known. Permit array-to-pointer decay on such arrays, but disallow pointer arithmetic (since we do not know whether it will have defined behavior). The standard is not clear on how this should work, but this seems to be a decent answer. Patch by Robert Haberlach! llvm-svn: 301822
2017-05-01Handle expressions with non-literal types like ignored expressions if we are ↵Nick Lewycky1-1/+7
supposed to continue evaluating them. Also fix a crash casting a derived nullptr to a virtual base. llvm-svn: 301785
2017-04-29Remove Sema::CheckForIntOverflow, and instead check all full-expressions.Nick Lewycky1-4/+9
CheckForIntOverflow used to implement a whitelist of top-level expressions to send to the constant expression evaluator, which handled many more expressions than the CheckForIntOverflow whitelist did. llvm-svn: 301742
2017-04-29ObjCBoxedExpr can't be evaluated by the constant expression evaluator.Nick Lewycky1-2/+5
A boxed expression evaluates its subexpr and then calls an objc method to transform it into another value with pointer type. The objc method can never be constexpr and therefore this expression can never be evaluated. Fixes a miscompile boxing expressions with side-effects. Also make ObjCBoxedExpr handling a normal part of the expression evaluator instead of being the only case besides full-expression where we check for integer overflow. llvm-svn: 301721
2017-04-27In the expression evaluator, visit the index of an ArraySubscriptExpr even ↵Nick Lewycky1-3/+8
if we can't evaluate the base, if the evaluation mode tells us to continue evaluation. llvm-svn: 301522
2017-04-27In the expression evaluator, descend into both the true and false ↵Nick Lewycky1-1/+7
expressions of a ConditionalOperator when the condition can't be evaluated and we're in an evaluation mode that says we should continue evaluating. llvm-svn: 301520
generated by cgit v1.1 at 2025-10-07 08:11:20 +0000