| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
loops to differ.
llvm-svn: 263895
|
|
|
|
| |
llvm-svn: 263371
|
|
|
|
|
|
| |
classes; these are initialized as if they were data members.
llvm-svn: 262963
|
|
|
|
|
|
|
|
|
|
|
|
| |
A member expression's base doesn't always have an impact on what the
member decl would evaluate to. In such a case, the base is used as a
poor man's scope qualifier.
This fixes PR26738.
Differential Revision: http://reviews.llvm.org/D17619
llvm-svn: 261975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the following bugs in __builtin_classify_type implementation:
1) Support for member functions and fields
2) Same behavior as GCC in C mode (specifically, return integer_type_class for
enums and pointer_type_class for function pointers and arrays). Behavior in
C++ mode didn't changed.
Also, it refactors the whole implementation, by replacing a sequence of
if-else-if with a couple of switches.
Differential Revision: http://reviews.llvm.org/D16846
llvm-svn: 260881
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a crash while parsing this code:
struct X {
friend constexpr int foo(X*) { return 12; }
static constexpr int j = foo(static_cast<X*>(nullptr));
};
Differential Revision: http://reviews.llvm.org/D16973
llvm-svn: 260675
|
|
|
|
| |
llvm-svn: 257802
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 257559
|
|
|
|
|
|
| |
That necessitated moving the OffsetOfNode class out of OffsetOfExpr.
llvm-svn: 256590
|
|
|
|
| |
llvm-svn: 255314
|
|
|
|
|
|
|
|
| |
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.
llvm-svn: 254992
|
|
|
|
|
|
|
| |
to treat as an ICE results in undefined behavior. Instead, return the "natural"
result of the operation (signed wraparound / inf / nan).
llvm-svn: 254699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 251528
|
|
|
|
|
|
| |
of await_* calls, and AST representation for same.
llvm-svn: 251387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r246877 made __builtin_object_size substantially more aggressive with
unknown bases if Type=1 or Type=3, which causes issues when we encounter
code like this:
struct Foo {
int a;
char str[1];
};
const char str[] = "Hello, World!";
struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str));
strcpy(&f->str, str);
__builtin_object_size(&f->str, 1) would hand back 1, which is
technically correct given the type of Foo, but the type of Foo lies to
us about how many bytes are available in this case.
This patch adds support for this "writing off the end" idiom -- we now
answer conservatively when we're given the address of the very last
member in a struct.
Differential Revision: http://reviews.llvm.org/D12169
llvm-svn: 250488
|
|
|
|
| |
llvm-svn: 248773
|
|
|
|
|
|
|
|
|
| |
The root cause here is that ObjCSelectorExpr is an rvalue, yet it can have its
address taken. That's kind of awkward, but fixing this is awkward in other
ways, see https://llvm.org/bugs/show_bug.cgi?id=24774#c16 . For now, just
fix the crash.
llvm-svn: 247740
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently there are many cast kinds that may cause implicit pointer
arithmetic to happen. In light of this, the cast ignoring logic
introduced in r246877 has been changed to only ignore a small set of
cast kinds, and a test for this behavior has been added.
Thanks to Richard for catching this before it became a bug report. :)
llvm-svn: 246890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improvements:
- For all types, we would give up in a case such as:
__builtin_object_size((char*)&foo, N);
even if we could provide an answer to
__builtin_object_size(&foo, N);
We now provide the same answer for both of the above examples in all
cases.
- For type=1|3, we now support subobjects with unknown bases, as long
as the designator is valid.
Thanks to Richard Smith for the review + design planning.
Review: http://reviews.llvm.org/D12169
llvm-svn: 246877
|
|
|
|
|
|
|
|
|
|
| |
We cannot tell if an object is past-the-end if its type is incomplete.
Zero sized objects satisfy past-the-end criteria and our object might
turn out to be such an object.
This fixes PR24622.
llvm-svn: 246359
|
|
|
|
|
|
| |
pointer to an RVO construction of a returned object.
llvm-svn: 246263
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_object_size would return incorrect answers for many uses where
type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's
objectsize intrinsic.
Additionally, there are many cases where we would emit suboptimal (but
correct) answers, such as when arrays are involved. This patch fixes
some of these cases (please see new tests in test/CodeGen/object-size.c
for specifics on which cases are improved)
Resubmit of r245323 with PR24493 fixed.
Patch mostly by Richard Smith.
Differential Revision: http://reviews.llvm.org/D12000
This fixes PR15212.
llvm-svn: 245403
|
|
|
|
| |
llvm-svn: 245342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_object_size would return incorrect answers for many uses where
type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's
objectsize intrinsic.
Additionally, there are many cases where we would emit suboptimal (but
correct) answers, such as when arrays are involved. This patch fixes
some of these cases (please see new tests in test/CodeGen/object-size.c
for specifics on which cases are improved)
Patch mostly by Richard Smith.
Differential Revision: http://reviews.llvm.org/D12000
This fixes PR15212.
llvm-svn: 245323
|
|
|
|
|
|
| |
copyable, make them movable instead
llvm-svn: 244829
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
|
|
|
|
|
|
| |
Patch by Косов Евгений!
llvm-svn: 238758
|
|
|
|
|
|
| |
emitted as a memcpy.
llvm-svn: 236142
|
|
|
|
|
|
| |
Found by -Wmissing-prototypes.
llvm-svn: 231668
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the NaN values emitted for MIPS architectures do not cover
non-IEEE754-2008 compliant case. This change fixes the issue.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D7882
llvm-svn: 230653
|
|
|
|
|
|
| |
macro. NFC; Clang edition.
llvm-svn: 229336
|
|
|
|
|
|
|
|
|
| |
When visiting AssignmentOps, keep evaluating after a failure (when possible) in
order to identify overflow in subexpressions.
Differential Revision: http://reviews.llvm.org/D1238
llvm-svn: 228202
|
|
|
|
|
|
| |
temporaries.
llvm-svn: 224449
|
|
|
|
|
|
| |
__attribute__((enable_if)), both in the condition expression and at the call site. Fixes PR20988!
llvm-svn: 224320
|
|
|
|
|
|
|
| |
Restricting this "extension" to array types maximizes our standards
conformance while not miscompiling real-world programs.
llvm-svn: 224215
|
|
|
|
|
|
|
|
| |
Comparing the address of an object with an incomplete type might return
true with a 'distinct' object if the former has a size of zero.
However, such an object should compare unequal with null.
llvm-svn: 224040
|
|
|
|
|
|
|
|
| |
Zero sized objects may overlap with each other or any other object.
This fixes PR21786.
llvm-svn: 223852
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL v2.0.
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.
llvm-svn: 222834
|
|
|
|
|
|
|
| |
empty non-constexpr object. Such a copy doesn't break any of the constexpr
rules.
llvm-svn: 222387
|
|
|
|
|
|
| |
constant expressions.
llvm-svn: 221942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
|
|
|
|
| |
llvm-svn: 220692
|
|
|
|
|
|
|
|
| |
complete object to a pointer to the start of another complete object does
not evaluate to the constant 'false'. All other comparisons between the
addresses of subobjects of distinct complete objects still do.
llvm-svn: 220343
|