summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaExpr.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [OPENMP 4.0] Initial support for array sections.Alexey Bataev2015-08-251-0/+167
| | | | | | | | Adds parsing/sema analysis/serialization/deserialization for array sections in OpenMP constructs (introduced in OpenMP 4.0). Currently it is allowed to use array sections only in OpenMP clauses that accepts list of expressions. Differential Revision: http://reviews.llvm.org/D10732 llvm-svn: 245937
* Fix crash with two typos in the arguments of a functionOlivier Goffart2015-08-201-0/+1
| | | | | | | | The problem is that the arguments are of TheCall are reset later to the ones in Args, making TypoExpr put back. Some TypoExpr that have already been diagnosed and will assert later in Sema::getTypoExprState llvm-svn: 245560
* Fix -Wlogical-not-parentheses to work better with C code.Richard Trieu2015-08-191-5/+2
| | | | | | | Remove the assumption of a Boolean type by checking if an expression is known to have a boolean value. Disable warning in two other tests. llvm-svn: 245507
* [SemaExpr] Re-enable missing assertion.Davide Italiano2015-08-191-2/+1
| | | | | | | | | | | | This has been disabled for a long time, but: 1) Initializers work (and apparently they're re reason why this was disabled). 2) various tests happen to hit this code path and the invariant seems to be always verified. Differential Revision: http://reviews.llvm.org/D12110 Reviewed by: rsmith llvm-svn: 245404
* [AST] ArrayRefize BlockDecl::setCaptures. No functionality change intended.Benjamin Kramer2015-08-051-2/+1
| | | | llvm-svn: 244027
* [SemaExpr] Factor out common diagnostic code for remainder/division.Davide Italiano2015-08-011-18/+16
| | | | llvm-svn: 243832
* Add support for System z vector language extensionsUlrich Weigand2015-07-301-20/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The z13 vector facility has an associated language extension, closely modeled on AltiVec/VSX. The main differences are: - vector long, vector float and vector pixel are not supported - vector long long and vector double are supported (like VSX) - comparison operators return a vector rather than a scalar integer - shift operators behave like the OpenCL shift operators - vector bool is only supported as argument to certain operators; some operators allow mixing a bool with a non-bool vector This patch adds clang support for the extension. It is closely modelled on the AltiVec support. Similarly to the -faltivec option, there's a new -fzvector option to enable the extensions (as well as an -mzvector alias for compatibility with GCC). There's also a separate LangOpt. The extension as implemented here is intended to be compatible with the -mzvector extension recently implemented by GCC. Based on a patch by Richard Sandiford. Differential Revision: http://reviews.llvm.org/D11001 llvm-svn: 243642
* [MS Extensions] Remove support for the i128 integer literal suffixDavid Majnemer2015-07-261-13/+1
| | | | | | | | | | | | | There is currently no support in MSVC for using i128 as an integer literal suffix. In fact, there appears to be no evidence that they have ever supported this feature in any of their compilers. This was an over generalization of their actual feature and is a nasty source of bugs. Why is it a source of bugs? Because most code in clang expects that evaluation of an integer constant expression won't give them something that 'long long' can't represent. Instead of providing a meaningful feature, i128 gives us cute ways of exploding the compiler. llvm-svn: 243243
* Fix the equal-vector-size rule for reinterpret_casts in C++John McCall2015-07-231-8/+18
| | | | | | | | | | | | | to consider the storage size of the vector instead of its sizeof. In other words, ban <3 x int> to <4 x int> casts, which produced invalid IR anyway. Also, attempt to be a little more rigorous, or at least explicit, about when enums are allowed in these casts. rdar://21901132 llvm-svn: 243069
* [Sema] Don't emit "pure virtual" warning for fully qualified calls.Davide Italiano2015-07-141-2/+3
| | | | | | | | | | -fapple-kext is an exception because calls will still go through the vtable in that mode. Add a note to make the user aware of that. PR: 23215 Differential Revision: http://reviews.llvm.org/D10935 llvm-svn: 242246
* [OPENMP] Drop type qualifiers from private variables.Alexey Bataev2015-07-141-0/+3
| | | | | | If the variable is marked as private in OpenMP construct, the reference to this variable should not keep type qualifiers for the original variable. Private copy is not volatile or constant, so we can use unqualified type for private copy. llvm-svn: 242133
* Improve the Objective-C common-type computation used by the ternary operator.Douglas Gregor2015-07-071-5/+5
| | | | | | | | | | | | | | | | The Objective-C common-type computation had a few problems that required a significant rework, including: - Quadradic behavior when finding the common base type; now it's linear. - Keeping around type arguments when computing the common type between a specialized and an unspecialized type - Introducing redundant protocol qualifiers. Part of rdar://problem/6294649. Also fixes rdar://problem/19572837 by addressing a longstanding bug in ASTContext::CollectInheritedProtocols(). llvm-svn: 241544
* Substitute type arguments into uses of Objective-C interface members.Douglas Gregor2015-07-071-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When messaging a method that was defined in an Objective-C class (or category or extension thereof) that has type parameters, substitute the type arguments for those type parameters. Similarly, substitute into property accesses, instance variables, and other references. This includes general infrastructure for substituting the type arguments associated with an ObjCObject(Pointer)Type into a type referenced within a particular context, handling all of the substitutions required to deal with (e.g.) inheritance involving parameterized classes. In cases where no type arguments are available (e.g., because we're messaging via some unspecialized type, id, etc.), we substitute in the type bounds for the type parameters instead. Example: @interface NSSet<T : id<NSCopying>> : NSObject <NSCopying> - (T)firstObject; @end void f(NSSet<NSString *> *stringSet, NSSet *anySet) { [stringSet firstObject]; // produces NSString* [anySet firstObject]; // produces id<NSCopying> (the bound) } When substituting for the type parameters given an unspecialized context (i.e., no specific type arguments were given), substituting the type bounds unconditionally produces type signatures that are too strong compared to the pre-generics signatures. Instead, use the following rule: - In covariant positions, such as method return types, replace type parameters with “id” or “Class” (the latter only when the type parameter bound is “Class” or qualified class, e.g, “Class<NSCopying>”) - In other positions (e.g., parameter types), replace type parameters with their type bounds. - When a specialized Objective-C object or object pointer type contains a type parameter in its type arguments (e.g., NSArray<T>*, but not NSArray<NSString *> *), replace the entire object/object pointer type with its unspecialized version (e.g., NSArray *). llvm-svn: 241543
* Handle Objective-C type arguments.Douglas Gregor2015-07-071-32/+2
| | | | | | | | | | | | | | | | | | | | | Objective-C type arguments can be provided in angle brackets following an Objective-C interface type. Syntactically, this is the same position as one would provide protocol qualifiers (e.g., id<NSCopying>), so parse both together and let Sema sort out the ambiguous cases. This applies both when parsing types and when parsing the superclass of an Objective-C class, which can now be a specialized type (e.g., NSMutableArray<T> inherits from NSArray<T>). Check Objective-C type arguments against the type parameters of the corresponding class. Verify the length of the type argument list and that each type argument satisfies the corresponding bound. Specializations of parameterized Objective-C classes are represented in the type system as distinct types. Both specialized types (e.g., NSArray<NSString *> *) and unspecialized types (NSArray *) are represented, separately. llvm-svn: 241542
* [Sema] Warn when shifting a negative value.Davide Italiano2015-07-061-2/+12
| | | | | | | | | | | | | | | Example: % ./clang -Wshift-negative-value emit.c emit.c:3:14: warning: shifting a negative signed value is undefined [-Wshift-negative-value] int a = -1 << 3; ~~ ^ 1 warning generated. PR: 24026 Differential Revision: http://reviews.llvm.org/D10938 Reviewed by: rsmith llvm-svn: 241478
* [OPENMP] Introduced type trait "__builtin_omp_required_simd_align" for ↵Alexey Bataev2015-07-021-1/+4
| | | | | | | | | default simd alignment. Adds type trait "__builtin_omp_required_simd_align" after discussions here http://reviews.llvm.org/D9894 Differential Revision: http://reviews.llvm.org/D10597 llvm-svn: 241237
* Make the typo resolution in r240441 apply to all function calls.Kaelyn Takata2015-06-231-11/+12
| | | | | | | | | | Regular function calls (such as to cabs()) run into the same problem with handling dependent exprs, not just builtins with custom type checking. Fixes PR23775. llvm-svn: 240443
* Ensure delayed typos have been corrected in calls to builtins beforeKaelyn Takata2015-06-231-1/+11
| | | | | | | | | checking those calls when not in C++ mode, since those code paths can't handle dependent exprs. Fixes PR23740. llvm-svn: 240441
* [OPENMP] Do not emit references to original variables in 'private' clause.Alexey Bataev2015-06-231-0/+15
| | | | | | | Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy. Differential Revision: http://reviews.llvm.org/D9550 llvm-svn: 240377
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-7/+7
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-7/+7
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Remove incomplete comment.Davide Italiano2015-06-221-1/+0
| | | | llvm-svn: 240252
* Consider unsigned long for non-u/U decimal literals (C90/C++03)Hubert Tong2015-06-081-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This modifies Clang to reflect that under pre-C99 ISO C, decimal constants may have type `unsigned long` even if they do not contain `u` or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is done for C++ without C++11 which--because of undefined behaviour--allows for behaviour compatible with ISO C90 in the case of an unsuffixed decimal literal and is otherwise identical to C90 in its treatment of integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2). Messages are added to the `c99-compat` and `c++11-compat` groups to warn on such literals, since they behave differently under the newer standards. Fixes PR 16678. Test Plan: A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit and 64-bit `long`. In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type using `__typeof__` and multiple declarations of the same entity. 2^63 is similarly tested when it is within the range of `unsigned long`. Preprocessor arithmetic tests are added to ensure consistency given that Clang (like GCC) uses greater than 32 bits for preprocessor arithmetic even when `long` and `unsigned long` is 32 bits and a pre-C99/C++11 mode is in effect. Tests added: test/Sema/PR16678.c Reviewers: fraggamuffin, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9794 llvm-svn: 239356
* [Sema] Promote compound assignment exprs. with fp16 LHS and int. RHS.Ahmed Bougacha2015-05-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | We catch most of the various other __fp16 implicit conversions to float, but not this one: __fp16 a; int i; ... a += i; For which we used to generate something 'fun' like: %conv = sitofp i32 %i to float %1 = tail call i16 @llvm.convert.to.fp16.f32(float %conv) %add = add i16 %0, %1 Instead, when we have an __fp16 LHS and an integer RHS, we should use float as the result type. While there, add a bunch of missing tests for mixed __fp16/integer expressions. llvm-svn: 238625
* Fix assertion when assigning to object in OpenCL constant address space.Richard Smith2015-05-221-0/+3
| | | | | | Patch by John Garvin! llvm-svn: 237983
* Check for bool-like conversion in conditional expressions.Richard Trieu2015-05-201-0/+2
| | | | | | | | | | Add a check for bool-like conversions for the condition expression of conditional operators. This is similiar to the checking of condition expressions of if statements, for-loops, while-loops, and do-while loops. Specificially, this is to fix the problem of assert("message") not triggering -Wstring-conversion when the assert macro uses a conditional operator. llvm-svn: 237856
* Fix Clang -Wsequence-pointDavid Blaikie2015-05-141-1/+1
| | | | llvm-svn: 237401
* Tweak availability checking to look through typedef declarations.Ted Kremenek2015-05-141-2/+18
| | | | llvm-svn: 237396
* Make GNUInline consistent with whether we use traditional GNU inline semantics.Peter Collingbourne2015-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were setting LangOptions::GNUInline (which controls whether we use traditional GNU inline semantics) if the language did not have the C99 feature flag set. The trouble with this is that C++ family languages also do not have that flag set, so we ended up setting this flag in C++ modes (and working around it in a few places downstream by also checking CPlusPlus). The fix is to check whether the C89 flag is set for the target language, rather than whether the C99 flag is cleared. This also lets us remove most CPlusPlus checks. We continue to test CPlusPlus when deciding whether to pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC. There is a change in semantics in two other places where we weren't checking both CPlusPlus and GNUInline (FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to put us back into line with GCC's semantics (test case: test/CodeGen/inline.c). While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it, it didn't have any effect before, and supporting it just makes things more complicated. Differential Revision: http://reviews.llvm.org/D9333 llvm-svn: 237299
* [modules] Stop trying to fake up a linear MacroDirective history.Richard Smith2015-04-291-3/+2
| | | | | | | | | | | | | | Modules builds fundamentally have a non-linear macro history. In the interest of better source fidelity, represent the macro definition information faithfully: we have a linear macro directive history within each module, and at any point we have a unique "latest" local macro directive and a collection of visible imported directives. This also removes the attendent complexity of attempting to create a correct MacroDirective history (which we got wrong in the general case). No functionality change intended. llvm-svn: 236176
* PR23334: Perform semantic checking of lambda capture initialization in the ↵Richard Smith2015-04-271-130/+23
| | | | | | | | | | | | | | | | | | right context. Previously we'd try to perform checks on the captures from the middle of parsing the lambda's body, at the point where we detected that a variable needed to be captured. This was wrong in a number of subtle ways. In PR23334, we couldn't correctly handle the list of potential odr-uses resulting from the capture, and our attempt to recover from that resulted in a use-after-free. We now defer building the initialization expression until we leave the lambda body and return to the enclosing context, where the initialization does the right thing. This patch only covers lambda-expressions, but we should apply the same change to blocks and captured statements too. llvm-svn: 235921
* [Objective-C Sema]This patch fixes the warning when clang issuesFariborz Jahanian2015-04-151-2/+1
| | | | | | | | | | "multiple methods named '<selector>' found" warning by noting the method that is actualy used. It also cleans up and refactors code in this area and selects a method that matches actual arguments in case of receiver being a forward class object. rdar://19265430 llvm-svn: 235023
* Improve the error message for assigning to read-only variables.Richard Trieu2015-04-111-3/+141
| | | | | | | | | | Previously, many error messages would simply be "read-only variable is not assignable" This change provides more information about why the variable is not assignable, as well as note to where the const is located. Differential Revision: http://reviews.llvm.org/D4479 llvm-svn: 234677
* Sema: Accept pointers to any address space for builtin functionsTom Stellard2015-03-311-3/+94
| | | | | | | | As long as they don't have an address space explicitly defined. This allows builtins with pointer arguments to be used with OpenCL. llvm-svn: 233706
* Fix -Wshift-count-negative. It didn't work if the right hand sideDavide Italiano2015-03-261-1/+1
| | | | | | | | of the shift wasn't a constant integer expression, now it (hopefully) does. PR: 22059 llvm-svn: 233320
* Add -Wpartial-availability.Nico Weber2015-03-191-7/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | This warns when using decls that are not available on all deployment targets. For example, a call to - (void)ppartialMethod __attribute__((availability(macosx,introduced=10.8))); will warn if -mmacosx-version-min is set to less than 10.8. To silence the warning, one has to explicitly redeclare the method like so: @interface Whatever(MountainLionAPI) - (void)ppartialMethod; @end This way, one cannot accidentally call a function that isn't available everywhere. Having to add the redeclaration will hopefully remind the user to add an explicit respondsToSelector: call as well. Some projects build against old SDKs to get this effect, but building against old SDKs suppresses some bug fixes -- see http://crbug.com/463171 for examples. The hope is that SDK headers are annotated well enough with availability attributes that new SDK + this warning offers the same amount of protection as using an old SDK. llvm-svn: 232750
* Remove many superfluous SmallString::str() calls.Yaron Keren2015-03-181-1/+1
| | | | | | | | | | | | | | | Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more. There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity. llvm-svn: 232622
* Reverted OpenCL2.0 atomic type commits r231932, r231935Anastasia Stulova2015-03-111-22/+0
| | | | | | (caused undesirable update of -std flag to use _Atomic) llvm-svn: 231942
* OpenCL: CL2.0 atomic type diagnosticsAnastasia Stulova2015-03-111-0/+22
| | | | | | Added restictions for atomic type usage from OpenCL C Spec Section 6.13.11.8 llvm-svn: 231935
* Sema: The i8 suffix should yield a literal of type charDavid Majnemer2015-03-061-0/+3
| | | | | | | | | We would make i8 literals turn into signed char instead of char. This is incompatible with MSVC. This fixes PR22824. llvm-svn: 231494
* Don't crash on non-public referenced dtors in toplevel classes.Nico Weber2015-03-061-2/+5
| | | | | | | Fixes PR22793, a bug that caused self-hosting to fail after the innocuous r231254. See the bug for details. llvm-svn: 231451
* Sema: Parenthesized bound destructor member expressions can be calledDavid Majnemer2015-02-251-1/+11
| | | | | | | | | We would wrongfully reject (a.~A)() in both the destructor and pseudo-destructor cases. This fixes PR22668. llvm-svn: 230512
* Restores r228382, which was reverted in r228406.Sameer Sahasrabuddhe2015-02-251-1/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The original commit failed to handle "shift assign" (<<=), which broke the test mentioned in r228406. This is now fixed and the test added to the lit tests under SemaOpenCL. *** Original commit message from r228382 *** OpenCL: handle shift operator with vector operands Introduce a number of checks: 1. If LHS is a scalar, then RHS cannot be a vector. 2. Operands must be of integer type. 3. If both are vectors, then the number of elements must match. Relax the requirement for "usual arithmetic conversions": When LHS is a vector, a scalar RHS can simply be expanded into a vector; OpenCL does not require that its rank be lower than the LHS. For example, the following code is not an error even if the implicit type of the constant literal is "int". char2 foo(char2 v) { return v << 1; } Consolidate existing tests under CodeGenOpenCL, and add more tests under SemaOpenCL. llvm-svn: 230464
* MS extensions: Properly diagnose address of MS property declReid Kleckner2015-02-241-0/+2
| | | | | | | | | | | | Summary: Fixes PR22671. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7863 llvm-svn: 230362
* Sema: Replace some push_backs of expensive to move objects with emplace_back.Benjamin Kramer2015-02-171-6/+3
| | | | | | NFC. llvm-svn: 229557
* Sema: Semantically check _Atomic-qualified pointersDavid Majnemer2015-02-121-5/+12
| | | | | | This fixes PR22568. llvm-svn: 228959
* Revert "OpenCL: handle shift operator with vector operands"Tom Stellard2015-02-061-65/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r228382. This breaks the following case: Reported by Jeroen Ketema: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150202/122961.html typedef __attribute__((ext_vector_type(3))) char char3; void foo() { char3 v = {1,1,1}; char3 w = {1,2,3}; w <<= v; } If I compile with: clang -x cl file.c Then an error is produced: file.c:10:5: error: expression is not assignable w <<= v; ~ ^ 1 error generated. llvm-svn: 228406
* OpenCL: handle shift operator with vector operandsSameer Sahasrabuddhe2015-02-061-1/+65
| | | | | | | | | | | | | | | | | | | | Introduce a number of checks: 1. If LHS is a scalar, then RHS cannot be a vector. 2. Operands must be of integer type. 3. If both are vectors, then the number of elements must match. Relax the requirement for "usual arithmetic conversions": When LHS is a vector, a scalar RHS can simply be expanded into a vector; OpenCL does not require that its rank be lower than the LHS. For example, the following code is not an error even if the implicit type of the constant literal is "int". char2 foo(char2 v) { return v << 1; } Consolidate existing tests under CodeGenOpenCL, and add more tests under SemaOpenCL. llvm-svn: 228382
* OpenCL: handle ternary operator when the condition is a vectorSameer Sahasrabuddhe2015-02-041-42/+194
| | | | | | | | | | When the condition is a vector, OpenCL specifies additional requirements on the operand types, and also the operations required to determine the result type of the operator. This is a combination of OpenCL v1.1 s6.3.i and s6.11.6, and the semantics remain unchanged in later versions of OpenCL. llvm-svn: 228118
* Fix OpenCL 1.2 double as an optional core feature behaviourFraser Cormack2015-01-301-1/+3
| | | | | | | | | | | | | | | | | | | | In OpenCL 1.2, using double no longer requires using the pragma cl_khr_fp64, instead a kernel is allowed to use double, but must first have queried clGetDeviceInfo's CL_DEVICE_DOUBLE_FP_CONFIG. Page 197, section 6.1.1 of the OpenCL 1.2 specification has a footnote 23 describing this behaviour. I've also added test cases such that the pragma must be used if targeting OpenCL 1.0 or 1.1, but is ignored in 1.2 and 2.0. Patch by Neil Henning! Reviewers: Pekka Jääskeläinen Differential Revision: http://reviews.llvm.org/D7245 llvm-svn: 227565
OpenPOWER on IntegriCloud