there is no reason to align them higher.
- This roughly matches llvm-gcc's r126913.
- It is an open question whether or not we should do this for cstring's in
general (code size vs optimization potential), for now we just match llvm-gcc
until someone wants to run some experiments.
llvm-svn: 129410
because the result is ignored. The particular example here is with
property l-values, but there could be all sorts of lovely casts that this
isn't safe for. Sink the check into the one case that seems to actually
be capable of honoring this.
llvm-svn: 129397
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
accessed via the indirect pointer, they don't need to be pointers to pointers).
Finished moving the message lookup code into separate subclasses for each
runtime. Also performed a few smallish related tidies.
We're now bitcasting the result of the message lookup functions, rather than
casting the lookup functions themselves, so the messages.m test needed updating
to reflect this.
llvm-svn: 128180
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
The prototype for objc_msgSend() is technically variadic -
`id objc_msgSend(id, SEL, ...)`.
But all method calls should use a prototype that matches the method,
not the prototype for objc_msgSend itself().
// rdar://9048030
llvm-svn: 126754
The prototype for objc_msgSend() is technically variadic -
`id objc_msgSend(id, SEL, ...)`.
But all method calls should use a prototype that matches the method,
not the prototype for objc_msgSend itself().
// rdar://9048030
llvm-svn: 126678
_Block_object_* flags; it's just BLOCK_HAS_COPY_DISPOSE or not.
Also, we don't need to chase forwarding pointers prior to calling
_Block_object_dispose; _Block_object_dispose in fact already does
this.
rdar://problem/9006315
llvm-svn: 125823
Nobody ever gave me a clear reason for why we were doing this, and
now it's apparently causing serious problems, so if *not* having this
causes problems, we get to solve them the right way this time.
llvm-svn: 125627
- BlockDeclRefExprs always store VarDecls
- BDREs no longer store copy expressions
- BlockDecls now store a list of captured variables, information about
how they're captured, and a copy expression if necessary
With that in hand, change IR generation to use the captures data in
blocks instead of walking the block independently.
Additionally, optimize block layout by emitting fields in descending
alignment order, with a heuristic for filling in words when alignment
of the end of the block header is insufficient for the most aligned
field.
llvm-svn: 125005
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
Also, move the l-value emission code into CGObjC.cpp and teach it, for
completeness, to store away self for a super send.
Also, inline the super cases for property gets and sets and make them
use the correct result type for implicit getter/setter calls.
llvm-svn: 120887
objc_exception_rethrow, so we don't...", since something is actually trying to
call this with the wrong signature (!). Unfortunately I don't understand the new
EH infrastructure well enough to fix it immediately.
llvm-svn: 116660
both @catches and a @finally, because the second call to @objc_exception_try_enter
will clobber the exception slot. Fixes rdar://problem/8440970.
llvm-svn: 115575
information when imported variable is used
more than once. Originally though to be a bug in importing
block varibles. Fixes radar 8417746.
llvm-svn: 113675
block-literal initializer expression causes IRgen to crash.
This patch fixes by saving it in StaticLocalDecl map
already used for such purposes. (radar 8390455).
llvm-svn: 113307
using the same methods as used for normal structures.
- This fixes problems with reading past the end of the structure and with
handling straddled bit-field access.
llvm-svn: 112914
instead of _Unwind_Resume. With SJLJ exceptions, this is spelled
"_Unwind_SjLj_Resume_or_Rethrow", not "_Unwind_SjLj_Resume", which has
significantly different semantics.
We should actually never be generating a call to _Unwind_SjLj_Resume directly;
even if we were generating true cleanups (which we aren't because of the
horrible hack), we should be calling __cxa_end_cleanup() on ARM. I
haven't implemented this because there's little point as long as the HH is
present.
I believe this fixes <rdar://problem/8281377>.
llvm-svn: 110851
where we weren't accounting for the possibility that a @finally block might
have internal cleanups and therefore might write to the cleanup destination slot.
Fixes <rdar://problem/8293901>.
llvm-svn: 110760
ObjC exceptions:
- don't enter a try for the catch blocks unless there's a finally
- put the setjmp buffer in the locals set for liveness reasons
- dump the sync object into an alloca in the locals set for liveness reasons
Some of this can go away if the backend starts to properly calculate liveness
in the presence of setjmp (which would also be a *much* stabler solution).
llvm-svn: 110188
the magic of inline assembly. Essentially we use read and write hazards
on the set of local variables to force flushing locals to memory
immediately before any protected calls and to inhibit optimizing locals
across the setjmp->catch edge. Fixes rdar://problem/8160285
llvm-svn: 109960
sections on", this change uncovered a possible linker bug which resulted in the
wrong messages getting dispatched. Backing this out while we investigate...
llvm-svn: 109817
use of property-dot syntax using 'super' as receiver
is 'void'. This fixes a bug in generating correct
API for setter call. Fixes radar 8203426.
llvm-svn: 109297
Devang Patel