summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
...
* [attributes] Add more tests for os_returns_retainedGeorge Karpenkov2018-12-061-3/+7
| | | | llvm-svn: 348443
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-0/+9
| | | | | | | | | 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-9/+0
| | | | | | | | | | 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
* Move AST tests into their own test directory; NFC.Aaron Ballman2018-11-307-142/+0
| | | | | | This moves everything primarily testing the functionality of -ast-dump and -ast-print into their own directory, rather than leaving the tests spread around the testing directory. llvm-svn: 348017
* [attributes] Add a family of OS_CONSUMED, OS_RETURNS and OS_RETURNS_RETAINED ↵George Karpenkov2018-11-302-0/+53
| | | | | | | | | | | | | | | | | | | | | attributes The addition adds three attributes for communicating ownership, analogous to existing NS_ and CF_ attributes. The attributes are meant to be used for communicating ownership of all objects in XNU (Darwin kernel) and all of the kernel modules. The ownership model there is very similar, but still different from the Foundation model, so we think that introducing a new family of attributes is appropriate. The addition required a sizeable refactoring of the existing code for CF_ and NS_ ownership attributes, due to tight coupling and the fact that differentiating between the types was previously done using a boolean. Differential Revision: https://reviews.llvm.org/D54912 llvm-svn: 347947
* Allow cpu-dispatch forward declarations.Erich Keane2018-11-281-4/+2
| | | | | | | | As a followup to r347805, allow forward declarations of cpu-dispatch and cpu-specific for the same reasons. Change-Id: Ic1bde9be369b1f8f1d47d58e6fbdc2f9dfcdd785 llvm-svn: 347812
* Correct 'target' default behavior on redecl, allow forward declaration.Erich Keane2018-11-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Declarations without the attribute were disallowed because it would be ambiguous which 'target' it was supposed to be on. For example: void ___attribute__((target("v1"))) foo(); void foo(); // Redecl of above, or fwd decl of below? void ___attribute__((target("v2"))) foo(); However, a first declaration doesn't have that problem, and erroring prevents it from working in cases where the forward declaration is useful. Additionally, a forward declaration of target==default wouldn't properly cause multiversioning, so this patch fixes that. The patch was not split since the 'default' fix would require implementing the same check for that case, followed by undoing the same change for the fwd-decl implementation. Change-Id: I66f2c5bc2477bcd3f7544b9c16c83ece257077b0 llvm-svn: 347805
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-0/+9
| | | | | | | 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
* PR39809: (const void*)0 is not a null pointer constant in C.Richard Smith2018-11-281-0/+7
| | | | llvm-svn: 347730
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [AArch64] Add aarch64_vector_pcs function attribute to ClangSander de Smalen2018-11-262-0/+21
| | | | | | | | | | | | | | | | | | | | This is the Clang patch to complement the following LLVM patches: https://reviews.llvm.org/D51477 https://reviews.llvm.org/D51479 More information describing the vector ABI and procedure call standard can be found here: https://developer.arm.com/products/software-development-tools/\ hpc/arm-compiler-for-hpc/vector-function-abi Patch by Kerry McLaughlin. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D54425 llvm-svn: 347571
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-0/+9
| | | | | | | | | 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-9/+0
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-0/+9
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* Revert 347294, it turned many bots on lab.llvm.org:8011/console red.Nico Weber2018-11-201-9/+0
| | | | llvm-svn: 347314
* Use is.constant intrinsic for __builtin_constant_pBill Wendling2018-11-201-0/+9
| | | | | | | | | | | | | | | | Summary: A __builtin_constant_p may end up with a constant after inlining. Use the is.constant intrinsic if it's a variable that's in a context where it may resolve to a constant, e.g., an argument to a function after inlining. Reviewers: rsmith, shafik Subscribers: jfb, kristina, cfe-commits, nickdesaulniers, jyknight Differential Revision: https://reviews.llvm.org/D54355 llvm-svn: 347294
* [Clang][Sema]Choose a better candidate in overload function call if there is ↵Zi Xuan Wu2018-11-161-0/+100
| | | | | | | | | | | | | | | | | | | | | | a compatible vector conversion instead of ambiguous call error There are 2 function variations with vector type parameter. When we call them with argument of different vector type we would prefer to choose the variation with implicit argument conversion of compatible vector type instead of incompatible vector type. For example, typedef float __v4sf __attribute__((__vector_size__(16))); void f(vector float); void f(vector signed int); int main { __v4sf a; f(a); } Here, we'd like to choose f(vector float) but not report an ambiguous call error. Differential revision: https://reviews.llvm.org/D53417 llvm-svn: 347019
* Reverted D52835 to fix review commentsDavid Bolvansky2018-11-142-51/+1
| | | | llvm-svn: 346866
* [Diagnostics] Check integer to floating point number implicit conversionsDavid Bolvansky2018-11-142-1/+51
| | | | | | | | | | | | | | | | | 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
* OpenCL: Don't warn on v printf modifierMatt Arsenault2018-11-131-0/+5
| | | | | | | | | | | This avoids spurious warnings, but could use a lot of work. For example the number of vector elements is not verified, and the passed value type is not checked. Fixes bug 39486 llvm-svn: 346806
* Support Swift in platform availability attributeMichael Wu2018-11-121-0/+29
| | | | | | | | | | | | | | Summary: This adds support for Swift platform availability attributes. It's largely a port of the changes made to https://github.com/apple/swift-clang/ for Swift availability attributes. Specifically, https://github.com/apple/swift-clang/commit/84b5a21c31cb5b0d7d958a478bc01964939b6952 and https://github.com/apple/swift-clang/commit/e5b87f265aede41c8381094bbf54e2715c8293b0 . The implementation of attribute_availability_swift is a little different and additional tests in test/Index/availability.c were added. Reviewers: manmanren, friss, doug.gregor, arphaman, jfb, erik.pilkington, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, ColinKinloch, jrmuizel, cfe-commits Differential Revision: https://reviews.llvm.org/D50318 llvm-svn: 346633
* [Diagnostics] Implement -Wsizeof-pointer-div David Bolvansky2018-11-011-0/+28
| | | | | | | | | | | | | | | | | | | Summary: void test(int *arr) { int arr_len = sizeof(arr) / sizeof(*arr); // warn, incorrect way to compute number of array elements } Enabled under -Wall (same behaviour as GCC) Reviewers: rsmith, MTC, aaron.ballman Reviewed By: aaron.ballman Subscribers: MTC, thakis, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D52949 llvm-svn: 345847
* Revert "Revert "Support for groups of attributes in #pragma clang attribute""Erik Pilkington2018-10-291-0/+23
| | | | | | | This reverts commit r345487, which reverted r345486. I think the crashes were caused by an OOM on the builder, trying again to confirm... llvm-svn: 345517
* Revert "Support for groups of attributes in #pragma clang attribute"Erik Pilkington2018-10-291-23/+0
| | | | | | | | | This reverts commit r345486. Looks like it causes some old versions of GCC to crash, I'll see if I can work around it and recommit... llvm-svn: 345487
* Support for groups of attributes in #pragma clang attributeErik Pilkington2018-10-291-0/+23
| | | | | | | | | | | | | | | | | | This commit enables pushing an empty #pragma clang attribute push, then adding multiple attributes to it, then popping them all with #pragma clang attribute pop, just like #pragma clang diagnostic. We still support the current way of adding these, #pragma clang attribute push(__attribute__((...))), by treating it like a combined push/attribute. This is needed to create macros like: DO_SOMETHING_BEGIN(attr1, attr2, attr3) // ... DO_SOMETHING_END rdar://45496947 Differential revision: https://reviews.llvm.org/D53621 llvm-svn: 345486
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-262-35/+55
| | | | | | | | | | | | 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
* Implement Function Multiversioning for Non-ELF Systems.Erich Keane2018-10-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the resolver function directly to forward the call to the proper function. This is not nearly as efficient as IFuncs of course, but is still quite useful for large functions specifically developed for certain processors. This is unfortunately still limited to x86, since it depends on __builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins. The naming for the resolver/forwarding function for cpu-dispatch was taken from ICC's implementation, which uses the unmodified name for this (no mangling additions). This is possible, since cpu-dispatch uses '.A' for the 'default' version. In 'target' multiversioning, this function keeps the '.resolver' extension in order to keep the default function keeping the default mangling. Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284 Differential Revision: https://reviews.llvm.org/D53586 llvm-svn: 345298
* Change getRedeclContext() to support enumerations as another kind of ↵Aaron Ballman2018-10-231-0/+23
| | | | | | | | transparent context in C. This change fixes PR15071 and ensures that enumerators redefined in a struct cannot conflict with enumerators defined outside of the struct. llvm-svn: 345073
* Silence the -Wshadow warning for enumerators shadowing a type.Aaron Ballman2018-10-221-0/+7
| | | | | | Amends r344259 so that enumerators shadowing types are not diagnosed, as shadowing under those circumstances is rarely (if ever) an issue in practice. llvm-svn: 344898
* [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsicsMandeep Singh Grang2018-10-181-0/+6
| | | | | | | | | | | | 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
* [Diagnostics] Check for integer overflow in array size expressions David Bolvansky2018-10-181-0/+3
| | | | | | | | | | | | | | Summary: Fixes PR27439 Reviewers: rsmith, Rakete1111 Reviewed By: rsmith Subscribers: Rakete1111, cfe-commits Differential Revision: https://reviews.llvm.org/D52750 llvm-svn: 344759
* [SystemZ] Actually enable -mzvector keywordsUlrich Weigand2018-10-162-0/+50
| | | | | | | | | | | | | | It appears when initially committing the support for the IBM Z vector extension language, one critical line was lost, causing the specific keywords __vector, __bool, and vec_step to not actually be enabled. (Note that this does not affect "vector" and "bool"!) Unfortunately, this was not caught by any tests either. (All existing Z vector tests just use the regular "vector" and "bool" keywords ...) Fixed by adding the missing line and updating the tests. llvm-svn: 344611
* Improve -Wshadow warnings with enumerators.Aaron Ballman2018-10-111-0/+5
| | | | | | | | | | | Addresses PR24718 by checking for enumerators that shadow other enumerators. Catches issues like: enum E1{e1}; void f(void) { enum E2{e1}; } llvm-svn: 344259
* [Basic] Split out -Wimplicit-int-conversion and -Wimplicit-float-conversion ↵Erik Pilkington2018-10-101-0/+15
| | | | | | | | | | | | | from -Wconversion These two diagnostics are noisy, so its reasonable for users to opt-out of them when -Wconversion is enabled. rdar://45058981 Differential revision: https://reviews.llvm.org/D53048 llvm-svn: 344101
* clang: Allow ifunc resolvers to accept argumentsEd Maste2018-10-101-4/+0
| | | | | | | | | | | | | | | | | | When ifunc support was added to Clang (r265917) it did not allow resolvers to take function arguments. This was based on GCC's documentation, which states resolvers return a pointer and take no arguments. However, GCC actually allows resolvers to take arguments, and glibc (on non-x86 platforms) and FreeBSD (on x86 and arm64) pass some CPU identification information as arguments to ifunc resolvers. I believe GCC's documentation is simply incorrect / out-of-date. FreeBSD already removed the prohibition in their in-tree Clang copy. Differential Revision: https://reviews.llvm.org/D52703 llvm-svn: 344100
* Emit CK_NoOp casts in C mode, not just C++.James Y Knight2018-10-051-0/+25
| | | | | | | | | | | | Previously, it had been using CK_BitCast even for casts that only change const/restrict/volatile. Now it will use CK_Noop where appropriate. This is an alternate solution to r336746. Differential Revision: https://reviews.llvm.org/D52918 llvm-svn: 343892
* [COFF, ARM64] Add __getReg intrinsicMandeep Singh Grang2018-10-041-0/+9
| | | | | | | | | | | | 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
* [SEMA] split ExtWarn dupl-decl-spec's into Extension and ExtWarnNick Desaulniers2018-10-031-0/+20
| | | | | | | | | | | | | | | | | | | | | | | Summary: For types deduced from typedef's and typeof's, don't warn for duplicate declaration specifiers in C90 unless -pedantic. Create a third diagnostic type for duplicate declaration specifiers. Previously, we had an ExtWarn and a Warning. This change adds a third, Extension, which only warns when -pedantic is set, staying silent otherwise. Fixes PR32985. Reviewers: rsmith Reviewed By: rsmith Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D52849 llvm-svn: 343740
* Remove spurious assertion in -WdocumentationReid Kleckner2018-10-021-0/+9
| | | | | | | | | | | Some code in OpenCV uses interesting doxygen directives that make it so we don't see any tokens inside a @note, despite there definitely being non-whitespace characters there. The consistency check isn't needed. ParagraphComment supports receiving an empty list of comments. Fixes PR39007 llvm-svn: 343641
* Added warning for unary minus used with unsigned typeDavid Bolvansky2018-10-021-0/+20
| | | | | | | | | | | | | | | | | 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
* Support enums with a fixed underlying type in all language modes.Erik Pilkington2018-09-281-0/+18
| | | | | | | | | | Previously we supported these in C++, ObjC, and C with -fms-extensions. rdar://43831380 Differential revision: https://reviews.llvm.org/D52339 llvm-svn: 343360
* Fix a bot failure from r343042.Erik Pilkington2018-09-251-2/+2
| | | | llvm-svn: 343050
* [Sema] Use a more civilized hash map to implement -Wduplicate-enum.Erik Pilkington2018-09-251-1/+9
| | | | | | | | | DenseMap<long, SOMETHING> used LONG_MAX as a tombstone, so it asserts when you try to insert it! rdar://44774672 llvm-svn: 343042
* Add inherited attributes before parsed attributes.Michael Kruse2018-09-243-8/+8
| | | | | | | | | | | | | | | | | Currently, attributes from previous declarations ('inherited attributes') are added to the end of a declaration's list of attributes. Before r338800, the attribute list was in reverse. r338800 changed the order of non-inherited (parsed from the current declaration) attributes, but inherited attributes are still appended to the end of the list. This patch appends inherited attributes after other inherited attributes, but before any non-inherited attribute. This is to make the order of attributes in the AST correspond to the order in the source code. Differential Revision: https://reviews.llvm.org/D50214 llvm-svn: 342861
* Thread Safety Analysis: warnings for attributes without argumentsAaron Puchert2018-09-201-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When thread safety annotations are used without capability arguments, they are assumed to apply to `this` instead. So we warn when either `this` doesn't exist, or the class is not a capability type. This is based on earlier work by Josh Gao that was committed in r310403, but reverted in r310698 because it didn't properly work in template classes. See also D36237. The solution is not to go via the QualType of `this`, which is then a template type, hence the attributes are not known because it could be specialized. Instead we look directly at the class in which we are contained. Additionally I grouped two of the warnings together. There are two issues here: the existence of `this`, which requires us to be a non-static member function, and the appropriate annotation on the class we are contained in. So we don't distinguish between not being in a class and being static, because in both cases we don't have `this`. Fixes PR38399. Reviewers: aaron.ballman, delesley, jmgao, rtrieu Reviewed By: delesley Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51901 llvm-svn: 342605
* test: actually fix the condition properlySaleem Abdulrasool2018-09-191-1/+1
| | | | | | | | I had locally changed the test to add an explicit triple to figure out the issue with the SCEI buildbots, and that hid the error. This now works with and without the explicit triple. llvm-svn: 342581
* test: improve condition for the checkSaleem Abdulrasool2018-09-191-1/+1
| | | | | | | When the type of `wint_t` is `int`, the promotion will allow this to pass. Check this explicitly rather than using the size. llvm-svn: 342569
* Sema: handle `wint_t` more carefully for printf checkingSaleem Abdulrasool2018-09-192-2/+5
| | | | | | | | | In the case that `win_t` is an `unsigned short` (e.g. on Windows), we would previously incorrectly diagnose the conversion because we would immediately promote the argument type from `wint_t` (aka `unsigned short`) to `int` before checking if the type matched. This should repair the Windows hosted bots. llvm-svn: 342565
* Basic: correct `__WINT_TYPE__` on WindowsSaleem Abdulrasool2018-09-191-2/+3
| | | | | | | | | Windows uses `unsigned short` for `wint_t`. Correct the type definition as vended by the compiler. This type is defined in corecrt.h and is unconditionally typedef'ed. cl does not have an equivalent to `__WINT_TYPE__` which is why this was never detected. llvm-svn: 342557
* [Diagnostic] Fix a warning typo. NFC.Matt Davis2018-09-122-2/+2
| | | | | | s/aligment/alignment/ llvm-svn: 342068
OpenPOWER on IntegriCloud