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

CharUnits. No change in functionality intended.

llvm-svn: 128126

Failures were due to new commands introduced.

llvm-svn: 128125

llvm-svn: 128124

platform connect <args>
platform disconnect

Each platform can decide the args they want to use for "platform connect". I 
will need to add a function that gets the connect options for the current
platform as each one can have different options and argument counts.

Hooked up more functionality in the PlatformMacOSX and PlatformRemoteiOS.
Also started an platform agnostic PlatformRemoteGDBServer.cpp which can end
up being used by one or more actual platforms. It can also be specialized and
allow for platform specific commands.

llvm-svn: 128123

Change inspired by llvm-bug 9530 submitted by Jyun-Yan You.

llvm-svn: 128122

on previous block parameters that crept in as part of my captures
work a month or so ago.

llvm-svn: 128121

A8.6.292 VCMPE

llvm-svn: 128120

llvm-svn: 128119

llvm-svn: 128118

This fixes kimwitu++, bullet, and tramp3dv4 with the ARM integrated assembler.
Fixes <rdar://problem/9165738>.

llvm-svn: 128117

that Stephen Wilson sent out.

llvm-svn: 128116

More fixes for ARM instruction emulation code:
  - Remove duplicate write from EmulateLDRRtPCRelative.
  - Add a missing encoding to EmulateADDSPImm.
  - Fix minor problems in Thumb instruction tables.

llvm-svn: 128115

This will extend the ranges of debug info variables in registers until they are
clobbered.

Fix 1: Don't mistake DBG_VALUE instructions referring to incoming arguments on
the stack with DBG_VALUE instructions referring to variables in the frame
pointer. This fixes the gdb test-suite failure.

Fix 2: Don't trace through copies to physical registers setting up call
arguments. These registers are call clobbered, and the source register is more
likely to be a callee-saved register that can be extended through the call
instruction.

llvm-svn: 128114

We now tag them as IndexModePost.

This fixed http://llvm.org/bugs/show_bug.cgi?id=9530.

llvm-svn: 128113

llvm-svn: 128112

autodetection is not yet implemented, but the structures and
register reading/writing code are there.

llvm-svn: 128111

both 32-bit and 64-bit targets.

llvm-svn: 128110

Simplify Mac runtime selection - it's the factory function's job to select which class to produce, not CodeGenModule's.

llvm-svn: 128109

memory and writing it back to disk.

llvm-svn: 128108

llvm-svn: 128107

llvm-svn: 128106

llvm-svn: 128105

Make the property accessor functions that take a ptrdiff_t actually take a ptrdiff_t instead of a long (should have no impact on any sane platforms, but win64 is not sane).

llvm-svn: 128104

VFP Load/Store Multiple Instructions used to embed the IA/DB addressing mode within the
MC instruction; that has been changed so that now, for example, VSTMDDB_UPD and VSTMDIA_UPD
are two instructions.  Update the ARMDisassemblerCore.cpp's DisassembleVFPLdStMulFrm()
to reflect the change.

Also add a test case.

llvm-svn: 128103

Make the ivar offset always be a ptrdiff_t, because stuff in CGObjC.cpp expects this.  Actually, it expects a long, but that's a bug that will be fixed in the next commit...

llvm-svn: 128102

Fixes rdar://9169640 

llvm-svn: 128100

llvm-svn: 128098

Temporarily reverting these to see if we can get llvm-objdump to link. Hopefully this is not the problem.

llvm-svn: 128097

llvm-svn: 128096

llvm-svn: 128095

llvm-svn: 128094

Support argument passing simple, common, prototypes directly. More
complicated scenarios will require building up a stub function, which the
MC-JIT isn't set up to handle yet.

Add Intercept.cpp, which is just a copy from ExecutionEngine/JIT for now,
to handle looking looking up external symbol names. This probably more
properly belongs as part of RuntimeDyld. It'll migrate there as things
flesh out more fully.

llvm-svn: 128090

llvm-svn: 128088

line options, instead of leveraging the blanket -mllvm option.
 - This allows using the frontend itself without requiring the backend have
   those options available (i.e., if the target wasn't built).

llvm-svn: 128087

llvm-svn: 128086

llvm-svn: 128085

llvm-svn: 128084

And clearing a SmallPtrSet can be an expensive operation.

llvm-svn: 128081

llvm-svn: 128077