With this patch, by a constexpr function is implicitly host+device
unless:
a) it's a variadic function (variadic functions are not allowed on the
device side), or
b) it's preceeded by a __device__ overload in a system header.
The restriction on overloading __host__ __device__ functions on the
basis of their CUDA attributes remains in place, but we use (b) to allow
us to define __device__ overloads for constexpr functions in cmath,
which would otherwise be __host__ __device__ and thus not overloadable.
You can disable this behavior with -fno-cuda-host-device-constexpr.
Reviewers: tra, rnk, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18380
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264964 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
IsOverload has a param named UseUsingDeclRules. But as far as I can
tell, it should be called UseMemberUsingDeclRules. That is, it only
applies to "using" declarations inside classes or structs.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18538
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264920 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* -fcuda-target-overloads
Previously unconditionally set to true by the driver. Necessary for
correct functioning of the compiler -- our CUDA headers wrapper won't
compile without this.
* -fcuda-disable-target-call-checks
Previously unconditionally set to true by the driver. Necessary to
compile almost any external CUDA code -- almost all libraries assume
that host+device code can call host or device functions.
* -fcuda-allow-host-calls-from-host-device
No effect when target overloading is enabled.
Reviewers: tra
Subscribers: rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D18416
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264739 91177308-0d34-0410-b5e6-96231b3b80d8
Also includes a minor ``enable_if`` docs update.
Currently, our address-of overload machinery will only allow implicit
conversions of overloaded functions to void* in C. For example:
```
void f(int) __attribute__((overloadable));
void f(double) __attribute__((overloadable, enable_if(0, "")));
void *fp = f; // OK. This is C and the target is void*.
void (*fp2)(void) = f; // Error. This is C, but the target isn't void*.
```
This patch makes the assignment of `fp2` select the `f(int)` overload,
rather than emitting an error (N.B. you'll still get a warning about the
`fp2` assignment if you use -Wincompatible-pointer-types).
Differential Revision: http://reviews.llvm.org/D13704
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@264132 91177308-0d34-0410-b5e6-96231b3b80d8
Some functions can't have their address taken. If we encounter an
overload set where only one of the candidates can have its address
taken, we should automatically select that candidate in cast
expressions.
Differential Revision: http://reviews.llvm.org/D17701
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263887 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the template cases in r262050, when a C++ method in an
unavailable struct/class calls unavailable API, don't diagnose an error.
I.e., this case was failing:
void foo() __attribute__((unavailable));
struct __attribute__((unavailable)) A {
void bar() { foo(); }
};
Since A is unavailable, A::bar is allowed to call foo. However, we were
emitting a diagnostic here. This commit checks up the context chain
from A::bar, in a manner inspired by SemaDeclAttr.cpp:isDeclUnavailable.
I expected to find other related issues but failed to trigger them:
- I wondered if DeclBase::getAvailability should check for
`TemplateDecl` instead of `FunctionTemplateDecl`, but I couldn't find
a way to trigger this. I left behind a few extra tests to make sure
we don't regress.
- I wondered if Sema::isFunctionConsideredUnavailable should be
symmetric, checking up the context chain of the callee (this commit
only checks up the context chain of the caller). However, I couldn't
think of a testcase that didn't require first referencing the
unavailable type; this, we already diagnose.
rdar://problem/25030656
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262921 91177308-0d34-0410-b5e6-96231b3b80d8
to allow arbitrary data to be associated with a parameter.
Also, fix a bug where we apparently haven't been serializing
this information for the last N years.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262278 91177308-0d34-0410-b5e6-96231b3b80d8
__global__ functions are present on both host and device side,
so providing __host__ or __device__ overloads is not going to
do anything useful.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@261778 91177308-0d34-0410-b5e6-96231b3b80d8
This is an artefact of split-mode CUDA compilation that we need to
mimic. HD functions are sometimes allowed to call H or D functions. Due
to split compilation mode device-side compilation will not see host-only
function and thus they will not be considered at all. For clang both H
and D variants will become function overloads visible to
compiler. Normally target attribute is considered only if C++ rules can
not determine which function is better. However in this case we need to
ignore functions that would not be present during current compilation
phase before we apply normal overload resolution rules.
Changes:
* introduced another level of call preference to better describe
possible call combinations.
* removed WrongSide functions from consideration if the set contains
SameSide function.
* disabled H->D, D->H and G->H calls. These combinations are
not allowed by CUDA and we were reluctantly allowing them to work
around device-side calls to math functions in std namespace.
We no longer need it after r258880.
Differential Revision: http://reviews.llvm.org/D16870
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260697 91177308-0d34-0410-b5e6-96231b3b80d8
For an explicit specialization, we first build a FunctionDecl, and then
we call SubstDecl() on it to build a second FunctionDecl, which has the
first FunctionDecl as canonical decl.
The address of an explicit specialization of function template used to be the
canonical decl of the FunctionDecl. This is different from all the other
DeduceTemplateArguments() calls in SemaOverload, and since the canonical decl
isn't visited by ParentMap while the redecl is, it also made ParentMap assert
when computing the parent of a address-of-explicit-specialization-fun-template.
To fix, remove the getCanonicalDecl() call. No behavior difference for clang,
but it fixes an assert in ParentMap (which is e.g. used by libTooling).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260159 91177308-0d34-0410-b5e6-96231b3b80d8
-Wdelete-non-virtual-dtor warns if A is a type with virtual functions but
without virtual dtor has its constructor called via `delete a`. This makes the
warning also fire if the dtor is called via `a->~A()`. This would've found a
security bug in Chromium at compile time. Fixes PR26137.
To fix the warning, add a virtual destructor, make the class final, or remove
its other virtual methods. If you want to silence the warning, there's also
a fixit that shows how:
test.cc:12:3: warning: destructor called on 'B' ... [-Wdelete-non-virtual-dtor]
b->~B();
^
test.cc:12:6: note: qualify call to silence this warning
b->~B();
^
B::
http://reviews.llvm.org/D16206
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257939 91177308-0d34-0410-b5e6-96231b3b80d8
In {CG,}ExprConstant.cpp, we weren't treating vector splats properly.
This patch makes us treat splats more properly.
Additionally, this patch adds a new cast kind which allows a bool->int
cast to result in -1 or 0, instead of 1 or 0 (for true and false,
respectively), so we can sanely model OpenCL bool->int casts in the AST.
Differential Revision: http://reviews.llvm.org/D14877
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257559 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257016 91177308-0d34-0410-b5e6-96231b3b80d8
by overload resolution because deduction succeeds, but the substituted
parameter type for some parameter (with deduced type) doesn't exactly match the
corresponding adjusted argument type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256657 91177308-0d34-0410-b5e6-96231b3b80d8
Doing so required separating them so that the former doesn't inherit
from the latter anymore. Investigating that, it became clear that the
inheritance wasn't actually providing real value in any case.
So also:
- Remove a bunch of redundant functions (getExplicitTemplateArgs,
getOptionalExplicitTemplateArgs) on various Expr subclasses which
depended on the inheritance relationship.
- Switched external callers to use pre-existing accessors that return the
data they're actually interested in (getTemplateArgs,
getNumTemplateArgs, etc).
- Switched internal callers to use pre-existing getTemplateKWAndArgsInfo.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256359 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
RequireCompleteType(..., 0) says we're not permitted to do so. The definition
might not be visible, even though we know what it is.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256045 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256037 91177308-0d34-0410-b5e6-96231b3b80d8
The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254646 91177308-0d34-0410-b5e6-96231b3b80d8
`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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254554 91177308-0d34-0410-b5e6-96231b3b80d8
the linkage of the enumeration. For enumerators of unnamed enumerations, extend
the -Wmodules-ambiguous-internal-linkage extension to allow selecting an
arbitrary enumerator (but only if they all have the same value, otherwise it's
ambiguous).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253010 91177308-0d34-0410-b5e6-96231b3b80d8
internal linkage entities in different modules from r250884 to apply to all
names, not just function names.
This is really awkward: we don't want to merge internal-linkage symbols from
separate modules, because they might not actually be defining the same entity.
But we don't want to reject programs that use such an ambiguous symbol if those
internal-linkage symbols are in fact equivalent. For now, we're resolving the
ambiguity by picking one of the equivalent definitions as an extension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252063 91177308-0d34-0410-b5e6-96231b3b80d8
We permit implicit conversion from pointer-to-function to
pointer-to-object when -fms-extensions is specified. This is rather
unfortunate, move this into -fms-compatibility and only permit it within
system headers unless -Wno-error=microsoft-cast is specified.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251738 91177308-0d34-0410-b5e6-96231b3b80d8
headers. If those headers end up being textually included twice into the same
module, we get ambiguity errors.
Work around this by downgrading the ambiguity error to a warning if multiple
identical internal-linkage functions appear in an overload set, and just pick
one of those functions as the lookup result.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250884 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250486 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@250090 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249995 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the order in which we evaluate the different ways that
a function call could be disallowed. Now, if you call a non-overloaded
function with an incomplete type and failing enable_if, we'll prioritize
reporting the more obvious error (use of incomplete type) over reporting
the failing enable_if.
Thanks to Ettore Speziale for the patch!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248595 91177308-0d34-0410-b5e6-96231b3b80d8
and fix the only code that was depending on this so that it sets all the
relevant flags appropriately.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248430 91177308-0d34-0410-b5e6-96231b3b80d8
The patch makes it possible to parse CUDA files that contain host/device
functions with identical signatures, but different attributes without
having to physically split source into host-only and device-only parts.
This change is needed in order to parse CUDA header files that have
a lot of name clashes with standard include files.
Gory details are in design doc here: https://goo.gl/EXnymm
Feel free to leave comments there or in this review thread.
This feature is controlled with CC1 option -fcuda-target-overloads
and is disabled by default.
Differential Revision: http://reviews.llvm.org/D12453
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248295 91177308-0d34-0410-b5e6-96231b3b80d8
for an existing entity, and as such a using-declaration doesn't need to
conflict with a hidden entity (nor vice versa).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247654 91177308-0d34-0410-b5e6-96231b3b80d8
The type of a member pointer is incomplete if it has no inheritance
model. This lets us reuse more general logic already embedded in clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247346 91177308-0d34-0410-b5e6-96231b3b80d8
The __kindof type qualifier can be applied to Objective-C object
(pointer) types to indicate id-like behavior, which includes implicit
"downcasting" of __kindof types to subclasses and id-like message-send
behavior. __kindof types provide better type bounds for substitutions
into unspecified generic types, which preserves more type information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241548 91177308-0d34-0410-b5e6-96231b3b80d8
Justin Lebar