the array alignment to the array access.
- This is more or less the best we can do without having alignment present in
the type system, but is a long way from truly matching how GCC handles this.
llvm-svn: 128691
Note this can potentially be enhanced to detect if the __block variable
is actually written by the block, or only when the block "escapes" or
is actually used, but that requires more analysis than it is probably worth
for this simple check.
llvm-svn: 128681
Models mempcpy() so that if length is NULL the destination pointer is returned. Otherwise, the source and destination are confirmed not to be NULL and not overlapping. Finally the copy is validated to not cause a buffer overrun and the return value is bound to the address of the byte after the last byte copied.
llvm-svn: 128677
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.
Found by inspection.
Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.
llvm-svn: 128618
from how we process ordinary function calls, had a tremendous about of redundancy, and relied
strictly on inlining behavior (which was incomplete) to provide semantics instead of falling
back to the conservative analysis we use for C functions. This is a significant step into
making C++ analyzer support more useful.
llvm-svn: 128557
when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.
The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.
Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.
llvm-svn: 128456
my expertise on the template instantiation logic isn't good enough to fix this problem for real. This patch worksaround the
problem in -Wuninitialized, but we should fix it for real later.
llvm-svn: 128443
and flesh out the existing uninitialized testing for field initializers.
The tests come from Richard's original patch, but I've cleaned them up
a bit and ordered them more naturally.
Also, I added a test for the most simple base case:
int x = x;
And it turns out we miss this one! =[ That and another bad FIXME on the
field initializer checking are left in the test.
llvm-svn: 128394
required modifying a few tests that specifically use note include stacks
to check the source manager's view of include stacks. I've simply added
the flag to these tests for now, they may have to be more substantially
changed if we decide to remove support for note include stacks
altogether.
Also, add a test for include stacks on notes that was supposed to go in
with the previous commit.
llvm-svn: 128390
This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.
Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.
llvm-svn: 128376
Emit them instead with the linkage of the VTT.
I'm actually really ambivalent about this; it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant. Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors; giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.
llvm-svn: 128374
platform implies default visibility. To achieve these, refactor our
lookup of explicit visibility so that we search for both an explicit
VisibilityAttr and an appropriate AvailabilityAttr, favoring the
VisibilityAttr if it is present.
llvm-svn: 128336
the following '@'. Conceivably, we could skip tokens until something that
can validly start an @interface declaration here, but it's not clear that
it matters.
llvm-svn: 128325
Fariborz Jahanian