| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 70941
|
| |
|
|
| |
llvm-svn: 70940
|
| |
|
|
|
|
|
| |
objc_assign_global API when assigning to global
objective-c object pointer.
llvm-svn: 70939
|
| |
|
|
|
|
|
|
|
|
|
|
| |
compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
- Also, we now report the size info for an empty class like gcc (as
the offset of the start, not as 0, 0).
- Add a few more test cases we were mishandling before (padding bit
field at end of struct, for example).
llvm-svn: 70938
|
| |
|
|
|
|
|
|
|
| |
layout.
- This is much simpler / more efficient.
- This also properly computes the size in the presence of bit-fields.
llvm-svn: 70916
|
| |
|
|
| |
llvm-svn: 70901
|
| |
|
|
| |
llvm-svn: 70897
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function calls. For a program like this:
#include <stdio.h>
static __inline__ __attribute__((always_inline))
int bar(int x) { return 4; }
int main() {
int X = bar(4);
printf("%d\n", X);
}
clang was not outputing any debug info for the body of main(). This is
because the backend is getting confused by the region_start/end that clang
is emitting for block scopes. For now, just disable these (matching llvm-gcc),
this stuff is in progress of rework anyway.
llvm-svn: 70889
|
| |
|
|
|
|
| |
control-flow expressions as dead.
llvm-svn: 70887
|
| |
|
|
|
|
|
| |
'==' and '!=' (some code in the '!=' was not replicated in the '==' code,
causing some constraints to get lost).
llvm-svn: 70885
|
| |
|
|
|
|
|
|
|
|
|
| |
'objc_ownership_cfretain' -> 'cf_ownership_retain'
'objc_ownership_cfrelease' -> 'cf_ownership_release'
Motivation: Core Foundation objects can be used in isolation from Objective-C,
and this forces users to reason about the separate semantics of CF objects. More
Sema support pending.
llvm-svn: 70884
|
| |
|
|
|
|
|
|
| |
return type and the selector. This is inconsistent with C functions
(where such attributes would be placed on the return type, not the the
FunctionDecl), and is inconsistent with what people are use to seeing.
llvm-svn: 70878
|
| |
|
|
|
|
|
|
| |
now be faster, and works in the presence of class posing. This is now the same approach as used in GCC (the earlier code was a quick hack to get something working)."
Patch by David Chisnall!
llvm-svn: 70877
|
| |
|
|
|
|
| |
Need to add Sema support.
llvm-svn: 70873
|
| |
|
|
|
|
| |
separate method.
llvm-svn: 70870
|
| |
|
|
| |
llvm-svn: 70869
|
| |
|
|
|
|
|
|
|
| |
The attached diff fixes the //FIXME in message send to super. This
should now be faster, and works in the presence of class posing. This
is now the same approach as used in GCC (the earlier code was a quick
hack to get something working).
llvm-svn: 70868
|
| |
|
|
|
|
| |
ElementRegions that have non-zero array indices.
llvm-svn: 70867
|
| |
|
|
| |
llvm-svn: 70865
|
| |
|
|
| |
llvm-svn: 70864
|
| |
|
|
|
|
|
| |
no-outofbounds.c still fails. Previously it passed because the array index
is mistakenly a loc::ConcreteInt.
llvm-svn: 70844
|
| |
|
|
|
|
|
| |
StoreManager: Handle casts from one element region to another.
Update test cases.
llvm-svn: 70836
|
| |
|
|
| |
llvm-svn: 70835
|
| |
|
|
|
|
| |
non-whitespace text with each expansion step. It's easier and seems to have better results.
llvm-svn: 70833
|
| |
|
|
|
|
|
|
|
| |
'ElementRegion' on top of the VarRegion for 'x'. This causes the test
case xfail_wine_crash.c to now pass for BasicStoreManager. It doesn't
crash for RegionStoreManager either, but reports a bogus unintialized
value warning.
llvm-svn: 70832
|
| |
|
|
|
|
|
|
|
| |
1) First of all, we treat _ as part of an identifier and not as
punctuation (oops).
2) Second of all, always make sure that the token that the ^ is
pointing at is fully within the "interesting" part of the range.
llvm-svn: 70831
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ElementRegion. I also removed 'ElementRegion::getArrayRegion',
although we may need to add this back.
This breaks a few test cases with RegionStore:
- 'array-struct.c' triggers an infinite recursion in RegionStoreManager. Need to investigate.
- misc-ps.m triggers a failure with RegionStoreManager as we now get the diagnostic:
'Line 159: Uninitialized or undefined return value returned to caller.'
There were a bunch of places that needed to be edit
RegionStoreManager, and we may not be passing all the correct 'element
types' down from GRExprEngine.
Zhongxing: When you get a chance, could you review this? I could have
easily screwed up something basic in RegionStoreManager.
llvm-svn: 70830
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in C++, taking into account conversions to the "composite pointer
type" so that we can compare, e.g., a pointer to a derived class to a
pointer to a base class.
Also, upgrade the "comparing distinct pointer types" from a warning to
an error for C++, since this is clearly an error. Turns out that we
hadn't gone through and audited this code for C++, ever.
Fixes <rdar://problem/6816420>.
llvm-svn: 70829
|
| |
|
|
|
|
|
| |
- Fix retain checker test failures.
- Update retain checker to have annotations override default summary effects, not completely redefine them.
llvm-svn: 70828
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This implements gcc style Objective-C interface layout (I
think). Currently it is always off, there is no functionality
change unless this is passed.
For the curious, the deal is that gcc lays out the fields of a
subclass as if they were part of the superclass. That is, the
subclass fields immediately follow the super class fields instead
of being padded to the alignment of the superclass structure.
- Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
llvm-gcc uses it in 32-bit only, for reasons which aren't clear
yet. We probably want to switch to matching gcc, once this makes it
through testing... my hope is that we can also fix llvm-gcc in
order to maintain compatibility between the compilers.
llvm-svn: 70827
|
| |
|
|
|
|
|
| |
which is returned instead of a null pointer. This helps centralize
the logic concerning "default effects".
llvm-svn: 70826
|
| |
|
|
| |
llvm-svn: 70825
|
| |
|
|
|
|
|
| |
We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.
llvm-svn: 70824
|
| |
|
|
|
|
| |
hopefully, this fixes PR4144 without any regressions.
llvm-svn: 70823
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
via CollectObjCIvars.
- In places where we need them, we should have the implementation and
access the properties through it.
This is a fairly substantial functionality change:
1. @encode no longer encodes synthesized ivars, ever.
2. The ivar layout bitmap no longer encodes information for
synthesized ivars in superclasses. Well, actually I had already
broken that, but it is intentional now.
We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.
Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.
I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.
llvm-svn: 70822
|
| |
|
|
| |
llvm-svn: 70813
|
| |
|
|
| |
llvm-svn: 70812
|
| |
|
|
| |
llvm-svn: 70810
|
| |
|
|
|
|
|
|
|
|
| |
- The diagnostic is still poor, however. Doug, can you investigate?
- Improved the test case to not depend on the file name, now it can
be extended to actually check the formatting of the diagnostics
(I'm hoping grep -A is portable here).
llvm-svn: 70807
|
| |
|
|
|
|
|
|
| |
stdint.h unless we are freestanding.
Any suggestions here are welcome.
llvm-svn: 70806
|
| |
|
|
|
|
| |
extension warning.
llvm-svn: 70805
|
| |
|
|
| |
llvm-svn: 70800
|
| |
|
|
|
|
|
| |
ivar layout.
- The layout needs access to synthesized ivars.
llvm-svn: 70798
|
| |
|
|
| |
llvm-svn: 70794
|
| |
|
|
|
|
| |
pasted token.
llvm-svn: 70793
|
| |
|
|
| |
llvm-svn: 70789
|
| |
|
|
| |
llvm-svn: 70786
|
| |
|
|
| |
llvm-svn: 70785
|
| |
|
|
|
|
| |
in C++. Fixes <rdar://problem/6815995>.
llvm-svn: 70784
|
| |
|
|
| |
llvm-svn: 70783
|