| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
but invalid designator.
llvm-svn: 318258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't try to map an APSInt addend to an int64_t in pointer arithmetic before
bounds-checking it. This gives more consistent behavior (outside C++11, we
consistently use 2s complement semantics for both pointer and integer overflow
in constant expressions) and fixes some cases where in C++11 we would fail to
properly check for out-of-bounds pointer arithmetic (if the 2s complement
64-bit overflow landed us back in-bounds).
In passing, also fix some cases where we'd perform possibly-overflowing
arithmetic on CharUnits (which have a signed underlying type) during constant
expression evaluation.
llvm-svn: 293595
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as 64 bit values for pointer arithmetic.
This fixes various ways to tickle an assertion in constant expression
evaluation when using __int128. Longer term, we need to figure out what should
happen here: either any kind of overflow in offset calculation should result in
a non-constant value or we should truncate to 64 bits. In C++11 onwards, we're
effectively already checking for overflow because we strictly enforce array
bounds checks, but even there some forms of overflow can slip past undetected.
llvm-svn: 293568
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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
|
|
|
|
|
|
| |
Patch by Косов Евгений!
llvm-svn: 238758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
null comparison when the pointer is known to be non-null.
This catches the array to pointer decay, function to pointer decay and
address of variables. This does not catch address of function since this
has been previously used to silence a warning.
Pointer to bool conversion is under -Wbool-conversion.
Pointer to null comparison is under -Wtautological-pointer-compare, a sub-group
of -Wtautological-compare.
void foo() {
int arr[5];
int x;
// warn on these conditionals
if (foo);
if (arr);
if (&x);
if (foo == null);
if (arr == null);
if (&x == null);
if (&foo); // no warning
}
llvm-svn: 202216
|
|
|
|
|
|
| |
constant evaluation. <rdar://problem/11874571>.
llvm-svn: 160394
|
|
|
|
|
|
| |
constant-folding relational comparisons safely in case the user is using -fwrapv or equivalent.
llvm-svn: 154849
|
|
|
|
|
|
| |
uncommon cases. <rdar://problem/10962435>.
llvm-svn: 154794
|
|
|
|
|
|
| |
from a constant string. Given that gcc doesn't accept this, we should continue to not accept it, even though it was accidentally supported by clang for a brief period.
llvm-svn: 154564
|
|
|
|
| |
llvm-svn: 151100
|
|
|
|
| |
llvm-svn: 149045
|
|
|
|
|
|
|
| |
bound to not have side effects(!). Add constant-folding support for expressions
of void type, to ensure that we can still fold ((void)0, 1) as an array bound.
llvm-svn: 146000
|
|
|
|
| |
llvm-svn: 144799
|
|
|
|
|
|
|
| |
not safely derived. Don't allow lvalue-to-rvalue conversions on the result of
dereferencing such a pointer.
llvm-svn: 144783
|
|
|
|
| |
llvm-svn: 144455
|
|
|
|
|
|
|
| |
be at the same address as another object, we do know it won't alias a null
pointer.
llvm-svn: 143674
|
|
|
|
|
|
| |
if it's marked as weak: that definition may not end up being used.
llvm-svn: 143496
|
|
|
|
|
|
| |
needed for C++11, and will follow later.
llvm-svn: 143363
|
|
|
|
| |
llvm-svn: 143320
|
|
|
|
|
|
| |
integer-cast pointer value.
llvm-svn: 143299
|
|
|
|
|
|
| |
binary operator isn't an rvalue if it's an assignment operator.
llvm-svn: 143250
|
|
|
|
|
|
|
|
|
|
| |
folded to a constant
as constant size arrays. This has slightly different semantics in some insane cases, but allows
us to accept some constructs that GCC does. Continue to be pedantic in -std=c99 and other
modes. This addressed rdar://8733881 - error "variable-sized object may not be initialized"; g++ accepts same code
llvm-svn: 132983
|
|
|
|
|
|
| |
list". Sorry, folks!
llvm-svn: 127188
|
|
|
|
| |
llvm-svn: 123759
|
|
|
|
| |
llvm-svn: 116317
|
|
|
|
| |
llvm-svn: 111080
|
|
|
|
|
|
| |
that we don't warn when there isn't going to be any computation anyway.
llvm-svn: 108442
|
|
|
|
|
|
|
|
|
|
| |
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
|
|
|
|
| |
llvm-svn: 96054
|
|
|
|
|
|
|
|
|
| |
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
|
|
|
|
|
|
| |
PR5449.
llvm-svn: 88885
|
|
|
|
|
|
| |
just for the unqualified, unaliased bool.
llvm-svn: 86174
|
|
|
|
|
|
| |
foo has a constant address.
llvm-svn: 73321
|
|
|
|
|
|
| |
correctly.
llvm-svn: 72886
|
|
|
|
| |
llvm-svn: 70317
|
|
|
|
|
|
|
| |
int. Note that constant int->complex float and float->complex int casts
were being miscompiled.
llvm-svn: 69821
|
|
|
|
|
|
| |
aggregates even though we already accept explicit ones. Easy fix.
llvm-svn: 69661
|
|
|
|
|
|
| |
Tests and drivers updated, still need to shuffle dirs.
llvm-svn: 67602
|
|
|
|
| |
llvm-svn: 67503
|
|
|
|
|
|
|
|
|
|
|
| |
will have the right type by the time the initializer is checked. This ensures that code like
int a[(int)(1.0 / 1.0) = { 1 } will work.
Eli, please review.
llvm-svn: 65725
|
|
|
|
|
|
| |
integer __real__ and __imag__. Not sure how I missed this.
llvm-svn: 65677
|
|
|
|
|
|
|
| |
expr; hilarity ensued.
- PR3640.
llvm-svn: 65234
|
|
|
|
| |
llvm-svn: 65105
|
|
|
|
|
|
| |
negative value.
llvm-svn: 65023
|