| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Given an expression like `(&Foo)();`, we perform overload resolution as
if we are calling `Foo` directly. This causes problems if `Foo` is a
function that can't have its address taken. This patch teaches overload
resolution to ignore functions that can't have their address taken in
such cases.
Differential Revision: http://reviews.llvm.org/D15590
llvm-svn: 257016
|
|
|
|
|
|
|
|
|
|
| |
instantiating a default argument expression.
This was previously just working implicitly by reinstantiating
in the current context, but caching means that we weren't
registering cleanups in subsequent uses.
llvm-svn: 256996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By storing the instantiated expression back in the ParmVarDecl,
we remove the last need for separately storing the sub-expression
of a CXXDefaultArgExpr. This makes PCH/Modules merging quite
simple: CXXDefaultArgExpr records are serialized as references
to the ParmVarDecl, and we ignore redundant attempts to overwrite
the instantiated expression.
This has some extremely marginal impact on user-facing semantics.
However, the major effect is that it avoids IRGen errors about
conflicting definitions due to lambdas in the argument being
instantiated multiple times while sharing the same mangling.
It should also slightly improve memory usage and module file size.
rdar://23810407
llvm-svn: 256983
|
|
|
|
|
|
| |
That necessitated moving the OffsetOfNode class out of OffsetOfExpr.
llvm-svn: 256590
|
|
|
|
| |
llvm-svn: 256576
|
|
|
|
|
|
|
|
|
|
| |
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
llvm-svn: 256575
|
|
|
|
| |
llvm-svn: 256349
|
|
|
|
| |
llvm-svn: 256135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
llvm-svn: 256049
|
|
|
|
|
|
|
|
| |
for the derived class into it. This is mostly just a cleanup, but could in
principle be a bugfix if there is some codepath that reaches here and didn't
previously require a complete type (I couldn't find any such codepath, though).
llvm-svn: 256037
|
|
|
|
|
|
| |
expressions to compliment '&' in '|' that is already present. Matches gcc behavior.
llvm-svn: 255450
|
|
|
|
|
|
| |
predicates already available in BinaryOperator. NFC
llvm-svn: 255449
|
|
|
|
| |
llvm-svn: 255428
|
|
|
|
|
|
| |
one of the expressions is a comparision op. Then if we find that either is a bitwise op, we know it must be the other one. NFC
llvm-svn: 255427
|
|
|
|
|
|
|
|
|
|
|
| |
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
llvm-svn: 255346
|
|
|
|
| |
llvm-svn: 255339
|
|
|
|
|
|
|
|
|
|
|
| |
address space unless address space is explicitly specified.
Correct the behavior of NULL constant detection -
generic AS void pointer should be accepted as a valid NULL constant.
http://reviews.llvm.org/D15293
llvm-svn: 255337
|
|
|
|
|
|
| |
instead of just unsigned. Removes a few explicit casts. NFC
llvm-svn: 255232
|
|
|
|
| |
llvm-svn: 255004
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`pass_object_size` is our way of enabling `__builtin_object_size` to
produce high quality results without requiring inlining to happen
everywhere.
A link to the design doc for this attribute is available at the
Differential review link below.
Differential Revision: http://reviews.llvm.org/D13263
llvm-svn: 254554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements the 4.5 specification for the implicit data maps. OpenMP 4.5 specification changes the default way data is captured into a target region. All the non-aggregate kinds are passed by value by default. This required activating the capturing by value during SEMA for the target region. All the non-aggregate values that can be encoded in the size of a pointer are properly casted and forwarded to the runtime library. On top of fixing the previous weird behavior for mapping pointers in nested data regions (an explicit map was always required), this also improves performance as the number of allocations/transactions to the device per non-aggregate map are reduced from two to only one - instead of passing a reference and the value, only the value passed.
Explicit maps will be added later on once firstprivate, private, and map clauses' SEMA and parsing are available.
Reviewers: hfinkel, rjmccall, ABataev
Subscribers: cfe-commits, carlo.bertolli
Differential Revision: http://reviews.llvm.org/D14940
llvm-svn: 254521
|
|
|
|
| |
llvm-svn: 254122
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC supports 'property' attribute and allows to apply it to the declaration of an empty array in a class or structure definition.
For example:
```
__declspec(property(get=GetX, put=PutX)) int x[];
```
The above statement indicates that x[] can be used with one or more array indices. In this case, i=p->x[a][b] will be turned into i=p->GetX(a, b), and p->x[a][b] = i will be turned into p->PutX(a, b, i);
Differential Revision: http://reviews.llvm.org/D13336
llvm-svn: 254067
|
|
|
|
| |
llvm-svn: 253315
|
|
|
|
| |
llvm-svn: 253155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
|
|
|
|
| |
llvm-svn: 252398
|
|
|
|
|
|
|
| |
its type decayed and qualifiers stripped when determining which
selection it matches. Fixes PR16340.
llvm-svn: 252104
|
|
|
|
|
|
| |
of await_* calls, and AST representation for same.
llvm-svn: 251387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
|
|
|
|
|
|
| |
offsetof handling code. Also use a range-based for loop. NFC
llvm-svn: 250989
|
|
|
|
|
|
| |
that uses back().
llvm-svn: 250970
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
|
|
|
|
|
|
|
|
|
|
| |
C allows for some implicit conversions that C++ does not, e.g. void* ->
char*. This patch teaches clang that these conversions are okay when
dealing with overloads in C.
Differential Revision: http://reviews.llvm.org/D13604
llvm-svn: 249995
|
|
|
|
| |
llvm-svn: 249801
|
|
|
|
|
|
|
|
|
| |
that change turns out to not be reasonable: mutating the AST of a parsed
template during instantiation is not a sound thing to do, does not work across
chained PCH / modules builds, and is in any case a special-case workaround to a
more general problem that should be solved centrally.
llvm-svn: 249342
|
|
|
|
| |
llvm-svn: 249259
|
|
|
|
|
|
|
|
|
| |
All global variables that are not enclosed in a declare target region
must be captured in the target region as local variables do. Currently,
there is no support for declare target, so this patch adds support for
capturing all the global variables used in a the target region.
llvm-svn: 249154
|
|
|
|
|
|
|
|
|
| |
We get into this bad state when someone defines a new member function
for a class but forgets to add the declaration to the class body.
Calling the new member function from a member function template of the
class will crash during instantiation.
llvm-svn: 248925
|
|
|
|
|
|
|
|
|
| |
and test checking broken (due to CL specific diagnostics) C functionality
M test/Sema/address_spaces.c
M lib/Sema/SemaExpr.cpp
llvm-svn: 248902
|
|
|
|
|
|
|
|
|
| |
Applied restrictions from OpenCL v2.0 s6.13.11.8
that mainly disallow operations on atomic types (except for taking their address - &).
The patch is taken from SPIR2.0 provisional branch, contributed by Guy Benyei!
llvm-svn: 248896
|
|
|
|
|
|
| |
OpenMP 4.1 allows to use array sections|subscript expressions in 'reduction' clauses. Added sema analysis, updated tests.
llvm-svn: 248880
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
|
|
|
|
|
|
| |
Previously, in certain cases lax vector conversions could occur between scalar floating-point values and ExtVector types; these conversions would be simple bitcasts. We need to allow them with other vector types to support some common headers, but we don't need them for ExtVector. Preventing them here makes them behave like other operations involving scalars and ExtVectors.
llvm-svn: 247643
|
|
|
|
|
|
|
|
|
| |
Given a reference to a pointer to member whose class's inheritance model
is unspecified, make sure we come up with an inheritance model in
plausible places. One place we were missing involved LValue to RValue
conversion, another involved unary type traits.
llvm-svn: 247248
|
|
|
|
|
|
| |
Fixed capturing of VLAs in 'private' clause of the OpenMP directives.
llvm-svn: 246757
|
|
|
|
|
|
|
|
| |
constructor or destructor function-try-block, which is UB in C++.
This corresponds to the CERT secure coding rule ERR53-CPP.
llvm-svn: 246548
|
|
|
|
|
|
|
|
| |
Reviewers: pekka.jaaskelainen
Differential Revision: http://reviews.llvm.org/D12470
llvm-svn: 246393
|
|
|
|
|
|
|
|
|
|
| |
We tried to provide a very nice diagnostic when diagnosing an assignment
to a const int & produced by a function call. However, we cannot always
determine what function was called.
This fixes PR24568.
llvm-svn: 246014
|
|
|
|
| |
llvm-svn: 245939
|