| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
'type' argument when it cannot be determined which objects ptr
points to at compile time. rdar://18334276
llvm-svn: 218258
|
|
|
|
|
|
|
|
|
| |
constexpr function. Part of this fix is a tentative fix for an as-yet-unfiled
core issue (we're missing a prohibition against reading mutable members from
unions via a trivial constructor/assignment, since that doesn't perform an
lvalue-to-rvalue conversion on the members).
llvm-svn: 217852
|
|
|
|
|
|
|
|
|
|
|
| |
This makes use of the recently-added @llvm.assume intrinsic to implement a
__builtin_assume(bool) intrinsic (to provide additional information to the
optimizer). This hooks up __assume in MS-compatibility mode to mirror
__builtin_assume (the semantics have been intentionally kept compatible), and
implements GCC's __builtin_assume_aligned as assume((p - o) & mask == 0). LLVM
now contains special logic to deal with assumptions of this form.
llvm-svn: 217349
|
|
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216528
|
|
|
|
|
|
| |
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
|
|
|
|
|
|
|
| |
or a class derived from T. We already supported this when initializing
_Atomic(T) from T for most (and maybe all) other reasonable values of T.
llvm-svn: 214390
|
|
|
|
|
|
|
| |
isOnePastTheEnd on an invalid designator, so assert and push the check into the
one caller that wasn't already checking.
llvm-svn: 213820
|
|
|
|
|
|
|
|
|
|
|
| |
The class seems to have an invariant that Entries is non-empty if
Invalid is false. It appears this method was previously private, and
all internal uses checked Invalid. Now there is an external caller, so
check Invalid to avoid array OOB underflow.
Fixes PR20420.
llvm-svn: 213816
|
|
|
|
|
|
|
|
| |
This is a follow-up to an IRC conversation with Richard last night; __assume
does not evaluate its argument, and so the argument should not contribute to
whether (__assume(e), constant) can be used where a constant is required.
llvm-svn: 213267
|
|
|
|
| |
llvm-svn: 212464
|
|
|
|
|
|
| |
expression because it uses 'this'. Inspired by PR20219 comment#2.
llvm-svn: 212433
|
|
|
|
| |
llvm-svn: 211987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
llvm-svn: 211677
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
This fixes PR19955.
llvm-svn: 211570
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
This fixes PR19955.
Differential Revision: http://reviews.llvm.org/D4250
llvm-svn: 211568
|
|
|
|
|
|
| |
non-literal class type.
llvm-svn: 210696
|
|
|
|
|
|
|
| |
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
|
|
|
|
| |
llvm-svn: 208517
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 205757
|
|
|
|
|
|
| |
iterator_range body(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 204040
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Gracefully fail to evaluate a constant expression if its type is
unknown, rather than failing an assertion trying to access the type.
Reviewers: klimek
Reviewed By: klimek
CC: chandlerc, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3075
llvm-svn: 203950
|
|
|
|
|
|
| |
iterator_range decls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203947
|
|
|
|
|
|
| |
iterator_range inits(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203819
|
|
|
|
|
|
|
|
| |
instead, per post-commit review feedback.
Replacing llvm::copy changes with SmallVector range-based construction which is a considerably cleaner approach.
llvm-svn: 203461
|
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
| |
Smith.
llvm-svn: 203262
|
|
|
|
|
|
| |
with iterator_range chains(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203261
|
|
|
|
|
|
| |
evaluating trivial default initialization of a literal class type.
llvm-svn: 203025
|
|
|
|
|
|
| |
Suggested by Richard Smith.
llvm-svn: 201753
|
|
|
|
|
|
|
|
|
|
| |
dependent expression
inside a GNU statement expression.
rdar://16064952
llvm-svn: 201468
|
|
|
|
|
|
|
|
| |
initialized from a constant expression in C++98, it can be used in
constant expressions, even if it was brace-initialized. Patch by
Rahul Jain!
llvm-svn: 200098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
|
|
| |
resolution based on the values of the function arguments at the call site.
llvm-svn: 198996
|
|
|
|
|
|
| |
so it has been removed. No functional changes intended.
llvm-svn: 198440
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
llvm-svn: 198271
|
|
|
|
|
|
|
|
| |
This better describes what the function does.
Cleanup only.
llvm-svn: 198127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
|
|
|
|
|
|
|
|
|
|
| |
With the introduction of explicit address space casts into LLVM, there's
a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA
and code to produce address space casts from those kinds when appropriate.
Patch by Michele Scandale!
llvm-svn: 197036
|
|
|
|
|
|
|
| |
where we didn't. Extend our constant evaluation for __builtin_strlen to handle
any constant array of chars, not just string literals, to match.
llvm-svn: 194762
|
|
|
|
|
|
| |
forget to clean up temporaries at the end of it.
llvm-svn: 194213
|
|
|
|
|
|
| |
when they actually do.
llvm-svn: 194156
|
|
|
|
|
|
|
| |
earlier 'non-constant' diagnostic with a later one if the earlier one was from
a side-effect we thought we could evaluate past.
llvm-svn: 194117
|
|
|
|
|
|
| |
checking an expression for constant overflow.
llvm-svn: 194099
|
|
|
|
|
|
|
|
|
| |
bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.
llvm-svn: 194098
|
|
|
|
|
|
| |
__builtin_isnan, and __builtin_isnormal. Patch by Karthik Bhat! Tests by me.
llvm-svn: 192729
|
|
|
|
| |
llvm-svn: 191171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
|
|
|
|
|
|
|
|
|
| |
Like any other type, an init list for a vector can have the same type as
the vector itself; handle that case.
<rdar://problem/14990460>
llvm-svn: 190844
|
|
|
|
|
|
| |
we try to constant-evaluate it. Patch by Karthik Bhat, test by me.
llvm-svn: 190722
|