summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaChecking.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Reverted D52835 to fix review commentsDavid Bolvansky2018-11-141-40/+8
| | | | llvm-svn: 346866
* [Diagnostics] Check integer to floating point number implicit conversionsDavid Bolvansky2018-11-141-8/+40
| | | | | | | | | | | | | | | | | Summary: GCC already catches these situations so we should handle it too. GCC warns in C++ mode only (does anybody know why?). I think it is useful in C mode too. Reviewers: rsmith, erichkeane, aaron.ballman, efriedma, xbolva00 Reviewed By: xbolva00 Subscribers: efriedma, craig.topper, scanon, cfe-commits Differential Revision: https://reviews.llvm.org/D52835 llvm-svn: 346865
* [mips][msa] Fix msa_[st/ld] offset checkAleksandar Beserminji2018-11-071-8/+8
| | | | | | | | | This patch fixes a minimum divider for offset in intrinsics msa_[st/ld]_[b/h/w/d], when value is known in compile time. Differential revision: https://reviews.llvm.org/D54038 llvm-svn: 346302
* os_log: Allow specifying mask type in format string.Akira Hatanaka2018-11-061-0/+6
| | | | | | | | | | A mask type is a 1 to 8-byte string that follows the "mask." annotation in the format string. This enables obfuscating data in the event the provided privacy level isn't enabled. rdar://problem/36756282 llvm-svn: 346211
* Reapply Logging: make os_log buffer size an integer constant expression.Tim Northover2018-11-021-1/+1
| | | | | | | | | | | | The size of an os_log buffer is known at any stage of compilation, so making it a constant expression means that the common idiom of declaring a buffer for it won't result in a VLA. That allows the compiler to skip saving and restoring the stack pointer around such buffers. This also moves the OSLog and other FormatString helpers from libclangAnalysis to libclangAST to avoid a circular dependency. llvm-svn: 345971
* NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)Erik Pilkington2018-10-301-1/+1
| | | | | | | | | | We haven't supported compiling ObjC1 for a long time (and never will again), so there isn't any reason to keep these separate. This patch replaces LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC. Differential revision: https://reviews.llvm.org/D53547 llvm-svn: 345637
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-261-2/+3
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* Avoid std::map&vector in hexagon builtin code to save code sizeReid Kleckner2018-10-251-763/+808
| | | | | | | | | | | | | | | | | | | | Constructing a global std::map requires clang to generate a linear amount of code to construct the initializer list if the elements are not constexpr-constructible. std::vector is not constexpr-constructible, so this code pattern was generating large amounts of code. Also, because of PR38829, LLVM is pathologically slow on large basic blocks, and this causes slow compilation. This works around the bug and reduces code size. SemaChecking.cpp -debug-info-kind=limited: time objsize before: 1m45.023s 9.8M after: 0m25.205s 6.9M So, a 42% obj size reduction and 3.2x speedup. llvm-svn: 345329
* [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsicsMandeep Singh Grang2018-10-181-0/+7
| | | | | | | | | | | | Reviewers: rnk, compnerd, mstorsjo, efriedma, TomTan, haripul, javed.absar Reviewed By: efriedma Subscribers: dmajor, kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D53115 llvm-svn: 344765
* [COFF, ARM64] Add __getReg intrinsicMandeep Singh Grang2018-10-041-0/+3
| | | | | | | | | | | | Reviewers: rnk, mstorsjo, compnerd, TomTan, haripul, javed.absar, efriedma Reviewed By: efriedma Subscribers: peter.smith, efriedma, kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D52838 llvm-svn: 343824
* Added warning for unary minus used with unsigned typeDavid Bolvansky2018-10-021-0/+13
| | | | | | | | | | | | | | | | | Summary: Inspired by MSVC, which found some occurrences of this expression on our code base. Fixes PR38950 Reviewers: rsmith, craig.topper, spatel, RKSimon, aaron.ballman, thakis Reviewed By: rsmith Subscribers: joerg, Quuxplusone, lebedev.ri, craig.topper, RKSimon, cfe-commits Differential Revision: https://reviews.llvm.org/D52137 llvm-svn: 343560
* [Sema] Handle __va_start for Windows/ARM64 in the same way as for ARMMartin Storsjo2018-09-271-0/+1
| | | | | | | | This fixes PR39090. Differential Revision: https://reviews.llvm.org/D52571 llvm-svn: 343184
* [OpenCL] Diagnose redundant address space conversionSven van Haastregt2018-09-201-0/+7
| | | | | | | | | | | | | | | | Add a warning if a parameter with a named address space is passed to a to_addr builtin. For example: int i; to_private(&i); // generate warning as conversion from private to private is redundant. Patch by Alistair Davies. Differential Revision: https://reviews.llvm.org/D51411 llvm-svn: 342638
* [PowerPC] [Clang] Add vector int128 pack/unpack builtinsQingShan Zhang2018-09-201-0/+12
| | | | | | | | | | | | unsigned long long builtin_unpack_vector_int128 (vector int128_t, int); vector int128_t builtin_pack_vector_int128 (unsigned long long, unsigned long long); Builtins should behave the same way as in GCC. Patch By: wuzish (Zixuan Wu) Differential Revision: https://reviews.llvm.org/D52074 llvm-svn: 342614
* Implement -Watomic-implicit-seq-cstJF Bastien2018-09-101-17/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: _Atomic and __sync_* operations are implicitly sequentially-consistent. Some codebases want to force explicit usage of memory order instead. This warning allows them to know where implicit sequentially-consistent memory order is used. The warning isn't on by default because _Atomic was purposefully designed to have seq_cst as the default: the idea was that it's the right thing to use most of the time. This warning allows developers who disagree to enforce explicit usage instead. A follow-up patch will take care of C++'s std::atomic. It'll be different enough from this patch that I think it should be separate: for C++ the atomic operations all have a memory order parameter (or two), but it's defaulted. I believe this warning should trigger when the default is used, but not when seq_cst is used explicitly (or implicitly as the failure order for cmpxchg). <rdar://problem/28172966> Reviewers: rjmccall Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51084 llvm-svn: 341860
* Remove deprecated APIStephen Kelly2018-09-061-8/+0
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50353 llvm-svn: 341573
* [Sema] Clean up some __builtin_*_chk diagnosticsErik Pilkington2018-09-061-8/+34
| | | | | | | | | | | Namely, print the likely macro name when it's used, and include the actual computed sizes in the diagnostic message, which are sometimes not obvious. rdar://43909200 Differential revision: https://reviews.llvm.org/D51697 llvm-svn: 341566
* [X86] Add kshift intrinsics to match gcc and icc.Craig Topper2018-08-311-0/+8
| | | | | | | | | | | | | | This adds the following intrinsics: _kshiftli_mask8 _kshiftli_mask16 _kshiftli_mask32 _kshiftli_mask64 _kshiftri_mask8 _kshiftri_mask16 _kshiftri_mask32 _kshiftri_mask64 llvm-svn: 341234
* [SEMA] add more -Wfloat-conversion to compound assigment analysisNick Desaulniers2018-08-131-27/+33
| | | | | | | | | | | | | | Summary: Fixes Bug: https://bugs.llvm.org/show_bug.cgi?id=27061 Reviewers: aaron.ballman, acoomans Reviewed By: aaron.ballman, acoomans Subscribers: acoomans, cfe-commits, srhines, pirama Differential Revision: https://reviews.llvm.org/D50467 llvm-svn: 339581
* Mark up deprecated methods as suchStephen Kelly2018-08-091-2/+8
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50352 llvm-svn: 339403
* Port getLocEnd -> getEndLocStephen Kelly2018-08-091-58/+57
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50351 llvm-svn: 339386
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-320/+300
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Add getEndLoc API to replace getLocEndStephen Kelly2018-08-091-1/+2
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50348 llvm-svn: 339374
* Add getBeginLoc API to replace getLocStartStephen Kelly2018-08-091-1/+2
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50346 llvm-svn: 339372
OpenPOWER on IntegriCloud