summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaChecking.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [clang] perform semantic checking in constant contextGauthier Harnisch2019-06-151-68/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 363488
* [X86] Add checks that immediate for reducesd/ss fits in 8-bits.Craig Topper2019-06-141-0/+2
| | | | llvm-svn: 363472
* For DR712: store on a DeclRefExpr whether it constitutes an odr-use.Richard Smith2019-06-111-9/+4
| | | | | | | Begin restructuring to support the forms of non-odr-use reference permitted by DR712. llvm-svn: 363086
* [mips] Check argument for __builtin_msa_ctcmsa / __builtin_msa_cfcmsaSimon Atanasyan2019-05-291-0/+2
| | | | | | | | | | | | | The `__builtin_msa_ctcmsa` and `__builtin_msa_cfcmsa` builtins are mapped to the `ctcmsa` and `cfcmsa` instructions respectively. While MSA control registers have indexes in 0..7 range, the instructions accept register index in 0..31 range [1]. [1] MIPS Architecture for Programmers Volume IV-j: The MIPS64 SIMD Architecture Module https://www.mips.com/?do-download=the-mips64-simd-architecture-module llvm-svn: 361967
* [X86] Fix the Sema checks for getmant builtins to only allow 4 and 8 for ↵Craig Topper2019-05-281-7/+4
| | | | | | | | | rounding immediates. These don't support embedded rounding so we shouldn't be setting HasRC. That way we only allow current direction and suppress all exceptions. llvm-svn: 361897
* Split ActOnCallExpr into an ActOnCallExpr to be called by the parser,Richard Smith2019-05-081-1/+1
| | | | | | | and a BuildCallExpr to be called internally within Sema to build / rebuild calls. llvm-svn: 360217
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-061-4/+5
| | | | | | | | | where either the modification or the other access is unreachable. This reverts r359984 (which reverted r359962). The bug in clang-tidy's test suite exposed by the original commit was fixed in r360009. llvm-svn: 360010
* Revert rL359962 : Use DiagRuntimeBehavior for -Wunsequenced to weed out ↵Simon Pilgrim2019-05-051-5/+4
| | | | | | | | | | false positives where either the modification or the other access is unreachable. ........ Try to fix buildbots llvm-svn: 359984
* Use DiagRuntimeBehavior for -Wunsequenced to weed out false positivesRichard Smith2019-05-041-4/+5
| | | | | | where either the modification or the other access is unreachable. llvm-svn: 359962
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-271-5/+1
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-261-0/+164
| | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
* Fix interactions between __builtin_constant_p and constexpr to matchRichard Smith2019-04-241-1/+5
| | | | | | | | | | | | | | | | | | current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359059
* [X86] Add some fp to integer conversion intrinsics to ↵Craig Topper2019-04-081-0/+4
| | | | | | | | Sema::CheckX86BuiltinRoundingOrSAE so their rounding controls will be checked. If we don't check this in the frontend we'll get an isel error in the backend later. This is far less friendly to users. llvm-svn: 357924
* Range-style std::find{,_if} -> llvm::find{,_if}. NFCFangrui Song2019-03-311-2/+1
| | | | llvm-svn: 357359
* [Sema] Avoid sending a dependent expression to the constant evaluator.Erik Pilkington2019-03-291-0/+3
| | | | | | Fixes llvm.org/PR41286 llvm-svn: 357304
* [Sema] Fix a crash when nonnull checkingMichael Liao2019-03-291-0/+3
| | | | | | | | | | | | | | | | | | | | Summary: - If a parameter is used, nonnull checking needs function prototype to retrieve the corresponding parameter's attributes. However, at the prototype substitution phase when a template is being instantiated, expression may be created and checked without a fully specialized prototype. Under such a scenario, skip nonnull checking on that argument. Reviewers: rjmccall, tra, yaxunl Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59900 llvm-svn: 357236
* Emit -Wfortify-source using DiagRuntimeBehaviourErik Pilkington2019-03-261-3/+4
| | | | | | | | | | This fixes a false positive on the following, where st is configured to have different sizes based on some preprocessor logic: if (sizeof(buf) == sizeof(*st)) memcpy(&buf, st, sizeof(*st)); llvm-svn: 357041
* [Sema] Don't check for array bounds when the types in the base expression ↵Bruno Ricci2019-03-251-0/+2
| | | | | | | | | | | | | | are dependent Bail-out of CheckArrayAccess when the types of the base expression before and after eventual casts are dependent. We will get another chance to check for array bounds during instantiation. Fixes PR41087. Differential Revision: https://reviews.llvm.org/D59776 Reviewed By: efriedma llvm-svn: 356957
* [Sema] Add some compile time _FORTIFY_SOURCE diagnosticsErik Pilkington2019-03-181-77/+138
| | | | | | | | | | | | | | | | | | | | | | | These diagnose overflowing calls to subset of fortifiable functions. Some functions, like sprintf or strcpy aren't supported right not, but we should probably support these in the future. We previously supported this kind of functionality with -Wbuiltin-memcpy-chk-size, but that diagnostic doesn't work with _FORTIFY implementations that use wrapper functions. Also unlike that diagnostic, we emit these warnings regardless of whether _FORTIFY_SOURCE is actually enabled, which is nice for programs that don't enable the runtime checks. Why not just use diagnose_if, like Bionic does? We can get better diagnostics in the compiler (i.e. mention the sizes), and we have the potential to diagnose sprintf and strcpy which is impossible with diagnose_if (at least, in languages that don't support C++14 constexpr). This approach also saves standard libraries from having to add diagnose_if. rdar://48006655 Differential revision: https://reviews.llvm.org/D58797 llvm-svn: 356397
* [Fixed Point Arithmetic] Fixed Point and Integer ConversionsLeonard Chan2019-03-061-3/+42
| | | | | | | | | This patch includes the necessary code for converting between a fixed point type and integer. This also includes constant expression evaluation for conversions with these types. Differential Revision: https://reviews.llvm.org/D56900 llvm-svn: 355462
* [Sema] Diagnose floating point conversions based on target semanticsErik Pilkington2019-02-161-11/+14
| | | | | | | | | | ...instead of just comparing rank. Also, fix a bad warning about _Float16, since its declared out of order in BuiltinTypes.def, meaning comparing rank using BuiltinType::getKind() is incorrect. Differential revision: https://reviews.llvm.org/D58254 llvm-svn: 354190
* [Sema] Fix-up a -Wfloat-conversion diagnosticErik Pilkington2019-02-141-10/+10
| | | | | | | | | | | | We were warning on valid ObjC property reference exprs, and passing in the wrong arguments to DiagnoseFloatingImpCast (leading to a badly worded diagnostic). rdar://47644670 Differential revision: https://reviews.llvm.org/D58145 llvm-svn: 354074
* [Builtins] Treat `bcmp` as a builtin.Clement Courbet2019-02-141-8/+8
| | | | | | | | | | | | | | | | | Summary: This makes it consistent with `memcmp` and `__builtin_bcmp`. Also see the discussion in https://reviews.llvm.org/D56593. Reviewers: jyknight Subscribers: kristina, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58120 llvm-svn: 354023
* Add a new builtin: __builtin_dynamic_object_sizeErik Pilkington2019-01-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This builtin has the same UI as __builtin_object_size, but has the potential to be evaluated dynamically. It is meant to be used as a drop-in replacement for libraries that use __builtin_object_size when a dynamic checking mode is enabled. For instance, __builtin_object_size fails to provide any extra checking in the following function: void f(size_t alloc) { char* p = malloc(alloc); strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", __builtin_object_size(p, 0)) } This is an overflow if alloc < 7, but because LLVM can't fold the object size intrinsic statically, it folds __builtin_object_size to -1. With __builtin_dynamic_object_size, alloc is passed through to __builtin___strcpy_chk. rdar://32212419 Differential revision: https://reviews.llvm.org/D56760 llvm-svn: 352665
* OpenCL: Use length modifier for warning on vector printf argumentsMatt Arsenault2019-01-291-2/+4
| | | | | | | | | | | | Re-enable format string warnings on printf. The warnings are still incomplete. Apparently it is undefined to use a vector specifier without a length modifier, which is not currently warned on. Additionally, type warnings appear to not be working with the hh modifier, and aren't warning on all of the special restrictions from c99 printf. llvm-svn: 352540
* Tentative fix for r351701 and gcc 6.2 build on ubuntuSerge Guelton2019-01-201-4/+4
| | | | llvm-svn: 351706
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* 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. llvm-svn: 351636
* [Fixed Point Arithmetic] Fixed Point Addition Constant Expression EvaluationLeonard Chan2019-01-181-0/+22
| | | | | | | | This patch includes logic for constant expression evaluation of fixed point additions. Differential Revision: https://reviews.llvm.org/D55868 llvm-svn: 351593
* [Sema] Change std::sort to llvm::sortMandeep Singh Grang2019-01-141-3/+3
| | | | llvm-svn: 351137
* Fix false positive unsequenced access and modification warning in array ↵Nicolas Lesser2019-01-101-16/+28
| | | | | | | | | | | | | | | | | | | | subscript expression. Summary: In the [expr.sub] p1, we can read that for a given E1[E2], E1 is sequenced before E2. Patch by Mateusz Janek. Reviewers: rsmith, Rakete1111 Reviewed By: rsmith, Rakete1111 Subscribers: riccibruno, lebedev.ri, Rakete1111, hiraditya, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50766 llvm-svn: 350874
* [Sema] Diagnose array access preceding the array bounds even when the base ↵Bruno Ricci2019-01-081-6/+9
| | | | | | | | | | | | | | | | | type is incomplete. When the type of the base expression after IgnoreParenCasts is incomplete, it is still possible to diagnose an array access which precedes the array bounds. This is a follow-up on D55862 which added an early return when the type of the base expression after IgnoreParenCasts was incomplete. Differential Revision: https://reviews.llvm.org/D56050 Reviewed By: efriedma llvm-svn: 350622
* [Sema][NFC] Remove some unnecessary calls to getASTContext.Bruno Ricci2018-12-211-2/+0
| | | | | | The AST context is already easily available. NFC. llvm-svn: 349904
* [Sema] Don't try to account for the size of an incomplete type in ↵Bruno Ricci2018-12-201-2/+10
| | | | | | | | | | | | | | | | | CheckArrayAccess When checking that the array access is not out-of-bounds in CheckArrayAccess it is possible that the type of the base expression after IgnoreParenCasts is incomplete, even though the type of the base expression before IgnoreParenCasts is complete. In this case we have no information about whether the array access is out-of-bounds and we should just bail-out instead. This fixes PR39746 which was caused by trying to obtain the size of an incomplete type. Differential Revision: https://reviews.llvm.org/D55862 Reviewed By: efriedma llvm-svn: 349811
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-181-4/+28
| | | | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. Patch by Bevin Hansson. llvm-svn: 349497
* [Clang] Add __builtin_launderEric Fiselier2018-12-141-0/+62
| | | | | | | | | | | | | | | | | Summary: This patch adds `__builtin_launder`, which is required to implement `std::launder`. Additionally GCC provides `__builtin_launder`, so thing brings Clang in-line with GCC. I'm not exactly sure what magic `__builtin_launder` requires, but based on previous discussions this patch applies a `@llvm.invariant.group.barrier`. As noted in previous discussions, this may not be enough to correctly handle vtables. Reviewers: rnk, majnemer, rsmith Reviewed By: rsmith Subscribers: kristina, Romain-Geissler-1A, erichkeane, amharc, jroelofs, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D40218 llvm-svn: 349195
* Revert r348889; it fails some tests.Aaron Ballman2018-12-111-22/+4
| | | | | | http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/40784 llvm-svn: 348892
* Emit -Wformat properly for bit-field promotions.Aaron Ballman2018-12-111-4/+22
| | | | | | Only explicitly look through integer and floating-point promotion where the result type is actually a promotion, which is not always the case for bit-fields in C. llvm-svn: 348889
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-1/+1
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* [Hexagon] Add intrinsics for Hexagon V66Krzysztof Parzyszek2018-12-051-735/+747
| | | | llvm-svn: 348419
* Do not check for parameters shadowing fields in function declarations.Aaron Ballman2018-12-051-0/+12
| | | | | | We would issue a false-positive diagnostic for parameters in function declarations shadowing fields; we now only issue the diagnostic on a function definition instead. llvm-svn: 348400
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-18/+29
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-29/+18
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-18/+29
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Derive builtin return type from its definitionMarco Antognini2018-11-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Prior to this patch, OpenCL code such as the following would attempt to create a BranchInst with a non-bool argument: if (enqueue_kernel(get_default_queue(), 0, nd, ^(void){})) /* ... */ This patch is a follow up on a similar issue with pipe builtin operations. See commit r280800 and https://bugs.llvm.org/show_bug.cgi?id=30219. This change, while being conservative on non-builtin functions, should set the type of expressions invoking builtins to the proper type, instead of defaulting to `bool` and requiring manual overrides in Sema::CheckBuiltinFunctionCall. In addition to tests for enqueue_kernel, the tests are extended to check other OpenCL builtins. Reviewers: Anastasia, spatel, rsmith Reviewed By: Anastasia Subscribers: kristina, cfe-commits, svenvh Differential Revision: https://reviews.llvm.org/D52879 llvm-svn: 347658
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-29/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-18/+29
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-29/+18
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-18/+29
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
OpenPOWER on IntegriCloud