| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 65021
|
|
|
|
|
|
| |
expressions as well.
llvm-svn: 65013
|
|
|
|
|
|
|
| |
Add assert to isICE that, on success, result must be the same as
EvaluateAsInt()... this enforces a minimum level of sanity.
llvm-svn: 64865
|
|
|
|
|
|
|
| |
mismatched semantics).
- Enforce this in APValue.
llvm-svn: 62924
|
|
|
|
| |
llvm-svn: 59939
|