aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/AST/ExprConstant.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-01-28[CUDA][HIP] Do not treat host var address as constant in device compilationYaxun (Sam) Liu1-2/+15
Currently clang treats host var address as constant in device compilation, which causes const vars initialized with host var address promoted to device variables incorrectly and results in undefined symbols. This patch fixes that. Reviewed by: Artem Belevich Differential Revision: https://reviews.llvm.org/D118153 Fixes: SWDEV-309881 Change-Id: I0a69357063c6f8539ef259c96c250d04615f4473
2022-01-10[Parse] Use empty RecoveryExpr when if/while/do/switch conditions fail to parseSam McCall1-2/+7
This allows the body to be parsed. An special-case that would replace a missing if condition with OpaqueValueExpr was removed as it's now redundant (unless recovery-expr is disabled). For loops are not handled at this point, as the parsing is more complicated. Differential Revision: https://reviews.llvm.org/D113752
2022-01-09[clang] Use true/false instead of 1/0 (NFC)Kazu Hirata1-1/+1
Identified with modernize-use-bool-literals.
2022-01-04Fix altivec regression caused by D115670 in Vec Const EvalErich Keane1-0/+9
The Vector Constant Evaluator assumes that all the types of its sub-expressions are going to be Vector APValues, which holds for most situations. However, in the 1 examples of Altivec C compilation of operator ++ (not allowed for other vector types), the result is an LValue. Since the operator isn't supported for constant evaluation anyway, this patch just fails-out of constant eval if we are in a situation where the operand to the unary operator causes an LValue.
2022-01-02[clang] Remove redundant member initialization (NFC)Kazu Hirata1-2/+2
Identified with readability-redundant-member-init.
2021-12-29Re-land "[clang] Add early exit when checking for const init of arrays."Sam McCall1-13/+40
This reverts commit 6d09aaecdfe51e13fc64d539aa7c9a790de341d7. The test uses ulimit and ran into problems on some bots. Run on linux only. There's nothing platform-specific about the code we're testing, so this should be enough to ensure correctness.
2021-12-20[Clang] Add __builtin_function_startSami Tolvanen1-5/+6
Control-Flow Integrity (CFI) replaces references to address-taken functions with pointers to the CFI jump table. This is a problem for low-level code, such as operating system kernels, which may need the address of an actual function body without the jump table indirection. This change adds the __builtin_function_start() builtin, which accepts an argument that can be constant-evaluated to a function, and returns the address of the function body. Link: https://github.com/ClangBuiltLinux/linux/issues/1353 Depends on D108478 Reviewed By: pcc, rjmccall Differential Revision: https://reviews.llvm.org/D108479
2021-12-17Implement some constexpr vector unary operators, fix boolean-opsErich Keane1-1/+84
As requested in the review, this implements unary +,-,~, and ! for vector types. All of our boolean operations on vector types should be using something like vcmpeqd, which results in a mask of '-1' for the 'truth' type. We are currently instead using '1', which results in some incorrect calculations when used later (note that it does NOT result in a boolean vector, as that is not really a thing). This patch corrects that 1 to be a -1, and updates the affected tests. Differential Revision: https://reviews.llvm.org/D115670
2021-12-06Introduce _BitInt, deprecate _ExtIntAaron Ballman1-1/+1
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-11-24[NFC][clang]Inclusive language: remove remaining uses of sanityZarko Todorovski1-1/+1
Missed some uses of sanity check in previous commits.
2021-11-10Revert "[clang] Add early exit when checking for const init of arrays."Adam Czachorowski1-40/+13
This reverts commit 48bb5f4cbe8d5951c1153e469dc6713a122b7fa3. Several breakages, including ARM (fixed later, but not sufficient) and MSan (to be diagnosed later). Differential Revision: https://reviews.llvm.org/D113599
2021-11-10[clang] Add early exit when checking for const init of arrays.Adam Czachorowski1-13/+40
Before this commit, on code like: struct S { ... }; S arr[10000000]; while checking if arr is constexpr, clang would reserve memory for arr before running constructor for S. If S turned out to not have a valid constexpr c-tor, clang would still try to initialize each element (and, in case the c-tor was trivial, even skipping the constexpr step limit), only to discard that whole APValue later, since the first element generated a diagnostic. With this change, we start by allocating just 1 element in the array to try out the c-tor and take an early exit if any diagnostics are generated, avoiding possibly large memory allocation and a lot of work initializing to-be-discarded APValues. Fixes 51712 and 51843. In the future we may want to be smarter about large possibly-constexrp arrays and maybe make the allocation lazy. Differential Revision: https://reviews.llvm.org/D113120
2021-10-27[AST] fail rather than crash when const evaluating invalid c++ foreachSam McCall1-0/+5
Differential Revision: https://reviews.llvm.org/D112633
2021-10-21Relax assert in ExprConstant to a return None.Jon Chesterfield1-2/+4
Fixes a compiler assert on passing a compile time integer to atomic builtins. Assert introduced in D61522 Function changed from ->bool to ->Optional in D76646 Simplifies call sites to getIntegerConstantExpr to elide the now-redundant isValueDependent checks. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D112159
2021-10-17[clang] Use llvm::erase_if (NFC)Kazu Hirata1-8/+4
2021-10-05Implement if consteval (P1938)Corentin Jabot1-1/+4
Modify the IfStmt node to suppoort constant evaluated expressions. Add a new ExpressionEvaluationContext::ImmediateFunctionContext to keep track of immediate function contexts. This proved easier/better/probably more efficient than walking the AST backward as it allows diagnosing nested if consteval statements.
2021-10-04[APInt] Stop using soft-deprecated constructors and methods in clang. NFC.Jay Foad1-3/+3
Stop using APInt constructors and methods that were soft-deprecated in D109483. This fixes all the uses I found in clang. Differential Revision: https://reviews.llvm.org/D110808
2021-09-28Change __builtin_sycl_unique_stable_name to just use an Itanium manglingErich Keane1-2/+0
After significant problems in our downstream with the previous implementation, the SYCL standard has opted to make using macros/etc to change kernel-naming-lambdas in any way UB (even passively). As a result, we are able to just emit the itanium mangling. However, this DOES require a little work in the CXXABI, as the microsoft and itanium mangler use different numbering schemes for lambdas. This patch adds a pair of mangling contexts that use the normal 'itanium' mangling strategy to fill in the "DeviceManglingNumber" used previously by CUDA. Differential Revision: https://reviews.llvm.org/D110281
2021-09-21[clang] don't mark as Elidable CXXConstruct expressions used in NRVOMatheus Izvekov1-3/+12
See PR51862. The consumers of the Elidable flag in CXXConstructExpr assume that an elidable construction just goes through a single copy/move construction, so that the source object is immediately passed as an argument and is the same type as the parameter itself. With the implementation of P2266 and after some adjustments to the implementation of P1825, we started (correctly, as per standard) allowing more cases where the copy initialization goes through user defined conversions. With this patch we stop using this flag in NRVO contexts, to preserve code that relies on that assumption. This causes no known functional changes, we just stop firing some asserts in a cople of included test cases. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D109800
2021-09-20[clang] Fix a few more comment typos to cycle botsNico Weber1-1/+1
2021-09-09[APInt] Normalize naming on keep constructors / predicate methods.Chris Lattner1-1/+1
This renames the primary methods for creating a zero value to `getZero` instead of `getNullValue` and renames predicates like `isAllOnesValue` to simply `isAllOnes`. This achieves two things: 1) This starts standardizing predicates across the LLVM codebase, following (in this case) ConstantInt. The word "Value" doesn't convey anything of merit, and is missing in some of the other things. 2) Calling an integer "null" doesn't make any sense. The original sin here is mine and I've regretted it for years. This moves us to calling it "zero" instead, which is correct! APInt is widely used and I don't think anyone is keen to take massive source breakage on anything so core, at least not all in one go. As such, this doesn't actually delete any entrypoints, it "soft deprecates" them with a comment. Included in this patch are changes to a bunch of the codebase, but there are more. We should normalize SelectionDAG and other APIs as well, which would make the API change more mechanical. Differential Revision: https://reviews.llvm.org/D109483
2021-08-25PR51105: look through ConstantExpr when looking for a braced string literal ↵Richard Smith1-1/+5
initialization.
2021-07-28[clang] Evaluate strlen of strcpy argument for -Wfortify-source.Michael Benfield1-40/+61
Also introduce Expr::tryEvaluateStrLen. Differential Revision: https://reviews.llvm.org/D104887
2021-06-30[clang][patch] Add builtin __arithmetic_fence and option fprotect-parensMelanie Blower1-0/+3
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the builtin is to provide the user fine control, at the expression level, over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. The builtin prevents the optimizer from rearranging floating point expression evaluation. The new option fprotect-parens has the same effect on parenthesized expressions, forcing the optimizer to respect the parentheses. Reviewed By: aaron.ballman, kpn Differential Revision: https://reviews.llvm.org/D100118
2021-06-28Revert "[clang][patch][fpenv] Add builtin __arithmetic_fence and option ↵Melanie Blower1-3/+0
fprotect-parens" This reverts commit 4f1238e44d803b145997fa984677a6c5cdf1f417. Buildbot fails on predecessor patch
2021-06-28[clang][patch][fpenv] Add builtin __arithmetic_fence and option fprotect-parensMelanie Blower1-0/+3
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the builtin is to provide the user fine control, at the expression level, over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. The builtin prevents the optimizer from rearranging floating point expression evaluation. The new option fprotect-parens has the same effect on parenthesized expressions, forcing the optimizer to respect the parentheses. Reviewed By: aaron.ballman, kpn Differential Revision: https://reviews.llvm.org/D100118
2021-06-11[ADT] Remove APInt/APSInt toString() std::string variantsSimon Pilgrim1-6/+6
<string> is currently the highest impact header in a clang+llvm build: https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps. This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code. Differential Revision: https://reviews.llvm.org/D103888
2021-06-09[clang] NFC: Rename rvalue to prvalueMatheus Izvekov1-29/+31
This renames the expression value categories from rvalue to prvalue, keeping nomenclature consistent with C++11 onwards. C++ has the most complicated taxonomy here, and every other language only uses a subset of it, so it's less confusing to use the C++ names consistently, and mentally remap to the C names when working on that context (prvalue -> rvalue, no xvalues, etc). Renames: * VK_RValue -> VK_PRValue * Expr::isRValue -> Expr::isPRValue * SK_QualificationConversionRValue -> SK_QualificationConversionPRValue * JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue" Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D103720
2021-05-27Reimplement __builtin_unique_stable_name-Erich Keane1-1/+23
The original version of this was reverted, and @rjmcall provided some advice to architect a new solution. This is that solution. This implements a builtin to provide a unique name that is stable across compilations of this TU for the purposes of implementing the library component of the unnamed kernel feature of SYCL. It does this by running the Itanium mangler with a few modifications. Because it is somewhat common to wrap non-kernel-related lambdas in macros that aren't present on the device (such as for logging), this uniquely generates an ID for all lambdas involved in the naming of a kernel. It uses the lambda-mangling number to do this, except replaces this with its own number (starting at 10000 for readabililty reasons) for lambdas used to name a kernel. Additionally, this implements itself as constexpr with a slight catch: if a name would be invalidated by the use of this lambda in a later kernel invocation, it is diagnosed as an error (see the Sema tests). Differential Revision: https://reviews.llvm.org/D103112
2021-04-10[Matrix] Implement C-style explicit type conversions for matrix types.Saurabh Jha1-0/+2
This implements C-style type conversions for matrix types, as specified in clang/docs/MatrixTypes.rst. Fixes PR47141. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D99037
2021-04-09Handle alloc_size attribute on function pointersAlex Richardson1-2/+5
I have been trying to statically find and analyze all calls to heap allocation functions to determine how many of them use sizes known at compile time vs only at runtime. While doing so I saw that quite a few projects use replaceable function pointers for heap allocation and noticed that clang was not able to annotate functions pointers with alloc_size. I have changed the Sema checks to allow alloc_size on all function pointers and typedefs for function pointers now and added checks that these attributes are propagated to the LLVM IR correctly. With this patch we can also compute __builtin_object_size() for calls to allocation function pointers with the alloc_size attribute. Reviewed By: aaron.ballman, erik.pilkington Differential Revision: https://reviews.llvm.org/D55212
2021-04-06[OpenMP] Define omp_is_initial_device() variants in omp.hHansang Bae1-3/+0
omp_is_initial_device() is marked as a built-in function in the current compiler, and user code guarded by this call may be optimized away, resulting in undesired behavior in some cases. This patch provides a possible fix for such cases by defining the routine as a variant function and removing it from builtin list. Differential Revision: https://reviews.llvm.org/D99447
2021-04-06Don't directly dereference getAs<> casts to avoid potential null ↵Simon Pilgrim1-4/+4
dereferences. NFCI. Replace with castAs<> which asserts the cast is valid. Fixes a number of static analyzer warnings.
2021-03-17PR49619: Remove delayed call to noteFailed.Richard Smith1-24/+7
This would assert if we hit the evaluation step limit between starting to delay the call and finishing. In any case, delaying the call was largely pointless as it doesn't really matter when we mark the evaluation as having had side effects.
2021-03-09PR49465: Disallow constant evaluation of a call to operator delete(nullptr).Richard Smith1-2/+5
The only time we would consider allowing this is inside a call to std::allocator<T>::deallocate, whose contract does not permit deletion of null pointers.
2021-02-18PR49239: Don't take shortcuts when constant evaluating in 'warn on UB'Richard Smith1-8/+10
mode. We use that mode when evaluating ICEs in C, and those shortcuts could result in ICE evaluation producing the wrong answer, specifically if we evaluate a statement-expression as part of evaluating the ICE.
2021-02-18[Clang][RISCV] Define RISC-V V builtin typesHsiangkai Wang1-0/+2
Add the types for the RISC-V V extension builtins. These types will be used by the RISC-V V intrinsics which require types of the form <vscale x 1 x i64>(LMUL=1 element size=64) or <vscale x 4 x i32>(LMUL=2 element size=32), etc. The vector_size attribute does not work for us as it doesn't create a scalable vector type. We want these types to be opaque and have no operators defined for them. We want them to be sizeless. This makes them similar to the ARM SVE builtin types. But we will have quite a bit more types. This patch adds around 60. Later patches will add another 230 or so types representing tuples of these types similar to the x2/x3/x4 types in ARM SVE. But with extra complexity that these types are combined with the LMUL concept that is unique to RISCV. For more background see this RFC http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html Authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Differential Revision: https://reviews.llvm.org/D92715
2021-02-08PR48606: The lifetime of a constexpr heap allocation always startedRichard Smith1-2/+2
during the same evaluation. It looks like the only case for which this matters is determining whether mutable subobjects of a heap allocation can be modified during constant evaluation.
2021-02-08PR48587: is_constant_evaluated() should not evaluate to true during aRichard Smith1-5/+14
variable's destruction if it didn't do so during construction. The standard doesn't give any guidance as to what to do here, but this approach seems reasonable and conservative, and has been proposed to the standard committee.
2021-02-04[AST] Update LVal before evaluating lambda decl fields.Zequan Wu1-1/+7
Differential Revision: https://reviews.llvm.org/D96092
2021-01-28[Clang][Codegen] Truncate initializers of union bitfield membersTomas Matheson1-1/+8
If an initial value is given for a bitfield that does not fit in the bitfield, the value should be truncated. Constant folding for expressions did not account for this truncation in the case of union member functions, despite a warning being emitted. In some contexts, evaluation of expressions was not enabled unless C++11, ROPI or RWPI was enabled. Differential Revision: https://reviews.llvm.org/D93101
2021-01-27[clang] Fix signedness in vector bitcast evaluationSven van Haastregt1-1/+1
The included test case triggered a sign assertion on the result in `Success()`. This was caused by the APSInt created for a bitcast having its signedness bit inverted. The second APSInt constructor argument is `isUnsigned`, so invert the result of `isSignedIntegerType`. Relanding this patch after reverting. The test case had to be updated to be insensitive to 32/64-bit extractelement indices. Differential Revision: https://reviews.llvm.org/D95135
2021-01-25Revert "[clang] Fix signedness in vector bitcast evaluation"Sven van Haastregt1-1/+1
This reverts commit 14947cd04701d923a57a0161fd1967b81e00ff5e because it broke clang-cmake-armv7-quick.
2021-01-25[clang] Fix signedness in vector bitcast evaluationSven van Haastregt1-1/+1
The included test case triggered a sign assertion on the result in `Success()`. This was caused by the APSInt created for a bitcast having its signedness bit inverted. The second APSInt constructor argument is `isUnsigned`, so invert the result of `isSignedIntegerType`. Differential Revision: https://reviews.llvm.org/D95135
2021-01-20Revert "[clang] Change builtin object size when subobject is invalid"George Burgess IV1-3/+3
This reverts commit 275f30df8ad6de75e1f29e4b33eaeb67686caf0d. As noted on the code review (https://reviews.llvm.org/D92892), this change causes us to reject valid code in a few cases. Reverting so we have more time to figure out what the right fix{es are, is} here.
2021-01-20Revert "Following up on PR48517, fix handling of template arguments that refer"Hans Wennborg1-59/+42
Combined with 'da98651 - Revert "DR2064: decltype(E) is only a dependent', this change (5a391d3) caused verifier errors when building Chromium. See https://crbug.com/1168494#c1 for a reproducer. Additionally it reverts changes that were dependent on this one, see below. > Following up on PR48517, fix handling of template arguments that refer > to dependent declarations. > > Treat an id-expression that names a local variable in a templated > function as being instantiation-dependent. > > This addresses a language defect whereby a reference to a dependent > declaration can be formed without any construct being value-dependent. > Fixing that through value-dependence turns out to be problematic, so > instead this patch takes the approach (proposed on the core reflector) > of allowing the use of pointers or references to (but not values of) > dependent declarations inside value-dependent expressions, and instead > treating template arguments as dependent if they evaluate to a constant > involving such dependent declarations. > > This ends up affecting a bunch of OpenMP tests, due to OpenMP > imprecisely handling instantiation-dependent constructs, bailing out > early instead of processing dependent constructs to the extent possible > when handling the template. > > Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and > reverted because a dependency commit was reverted. This reverts commit 5a391d38ac6c561ba908334d427f26124ed9132e. It also restores clang/test/SemaCXX/coroutines.cpp to its state before da986511fb9da1a46a0ca4dba2e49e2426036303. Revert "[c++20] P1907R1: Support for generalized non-type template arguments of scalar type." > Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and > reverted because a dependency commit was reverted. This incorporates the > following follow-on commits that were also reverted: > > 7e84aa1b81e72d44bcc58ffe1731bfc7abb73ce0 by Simon Pilgrim > ed13d8c66781b50ff007cb089c5905f9bb9e8af2 by me > 95c7b6cadbc9a3d4376ef44edbeb3c8bb5b8d7fc by Sam McCall > 430d5d8429473c2b10b109991d7577a3cea41140 by Dave Zarzycki This reverts commit 4b574008aef5a7235c1f894ab065fe300d26e786. Revert "[msabi] Mangle a template argument referring to array-to-pointer decay" > [msabi] Mangle a template argument referring to array-to-pointer decay > applied to an array the same as the array itself. > > This follows MS ABI, and corrects a regression from the implementation > of generalized non-type template parameters, where we "forgot" how to > mangle this case. This reverts commit 18e093faf726d15f210ab4917142beec51848258.
2021-01-18Following up on PR48517, fix handling of template arguments that referRichard Smith1-42/+59
to dependent declarations. Treat an id-expression that names a local variable in a templated function as being instantiation-dependent. This addresses a language defect whereby a reference to a dependent declaration can be formed without any construct being value-dependent. Fixing that through value-dependence turns out to be problematic, so instead this patch takes the approach (proposed on the core reflector) of allowing the use of pointers or references to (but not values of) dependent declarations inside value-dependent expressions, and instead treating template arguments as dependent if they evaluate to a constant involving such dependent declarations. This ends up affecting a bunch of OpenMP tests, due to OpenMP imprecisely handling instantiation-dependent constructs, bailing out early instead of processing dependent constructs to the extent possible when handling the template. Previously committed as 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e, and reverted because a dependency commit was reverted.
2021-01-07[clang] Change builtin object size when subobject is invalidJeffrey T Mott1-3/+3
Motivating example: ``` struct { int v[10]; } t[10]; __builtin_object_size( &t[0].v[11], // access past end of subobject 1 // request remaining bytes of closest surrounding // subobject ); ``` In GCC, this returns 0. https://godbolt.org/z/7TeGs7 In current clang, however, this returns 356, the number of bytes remaining in the whole variable, as if the `type` was 0 instead of 1. https://godbolt.org/z/6Kffox This patch checks for the specific case where we're requesting a subobject's size (type 1) but the subobject is invalid. Differential Revision: https://reviews.llvm.org/D92892
2020-12-22Revert "Following up on PR48517, fix handling of template arguments that refer"Arthur Eubanks1-59/+42
This reverts commit 8c1f2d15b826591cdf6bd6b468b8a7d23377b29e. This is part of 5 commits being reverted due to https://crbug.com/1161059. See bug for repro.
2020-12-17Following up on PR48517, fix handling of template arguments that referRichard Smith1-42/+59
to dependent declarations. Treat an id-expression that names a local variable in a templated function as being instantiation-dependent. This addresses a language defect whereby a reference to a dependent declaration can be formed without any construct being value-dependent. Fixing that through value-dependence turns out to be problematic, so instead this patch takes the approach (proposed on the core reflector) of allowing the use of pointers or references to (but not values of) dependent declarations inside value-dependent expressions, and instead treating template arguments as dependent if they evaluate to a constant involving such dependent declarations. This ends up affecting a bunch of OpenMP tests, due to OpenMP imprecisely handling instantiation-dependent constructs, bailing out early instead of processing dependent constructs to the extent possible when handling the template.
generated by cgit v1.1 at 2025-10-05 15:13:25 +0000