compatible with VC++ and GCC.  The codegen/mangling angle hasn't
been fully ironed out yet.  Note that we accept int128_t even in
32-bit mode, unlike gcc.

llvm-svn: 70464

It seems to effect code gen. Add a FIXME instead.

llvm-svn: 70423

referenced in a category implementation meta-data
(Next objc 32bit abi).

llvm-svn: 70407

llvm-svn: 70404

mode and in the presence of __gnu_inline__ attributes. This should fix
both PR3989 and PR4069.

As part of this, we now keep track of all of the attributes attached
to each declaration even after we've performed declaration
merging. This fixes PR3264.

llvm-svn: 70292

llvm-svn: 70266

member.

Also, spell bitfield more consistently as bit-field.

llvm-svn: 70220

llvm-svn: 70155

llvm-svn: 70145

llvm-svn: 70136

instead of passing it around in addition to it.

llvm-svn: 70135

the enum along with some other data.

llvm-svn: 70114

llvm-svn: 70105

When calling the cleanup function specified by __attribute__((cleanup)), make sure to bitcast the argument so it has the same type as the first argument of the cleanup function. Fixes <rdar://problem/6827047>.

llvm-svn: 70098

"This fixes message sends to super in a way that both works with real code and passes the test in the test suite.  It also fixes a crash when using recent versions of GNU libobjc and compiling modules that do not contain any constant strings but do contain a declaration of the constant string class and possible some other corner cases (thanks to Pete French for providing me with a test case for that one)."

Patch by David Chisnall!

llvm-svn: 70093

llvm-svn: 70091

llvm-svn: 70067

types.
 - I broke this in the switch to representing interfaces with opaque
   types.

 - <rdar://problem/6822660> clang crashes on subscript of interface in
   32-bit mode

llvm-svn: 70009

llvm-svn: 69988

llvm-svn: 69979

llvm-svn: 69970

llvm-svn: 69949

multiple declarations of the function. Should fix PR3989 and
<rdar://problem/6818429>.

llvm-svn: 69905

Handle corner case where clang-cc is invoked directly to compile preprocessed source file without -main-file-name. In this case, CDDebugInfo is not able identify correct main source file becase SM.isFromMainFile() returns true for locations from header files as well as locations from main source file.
This patch takes conservative approach by not emitting more then one compile unit with isMain bit set.

llvm-svn: 69902

llvm-svn: 69896

 - This shouldn't change anything, we never actually access it, but
   this is consistent with llvm-gcc (and 32-bit)

llvm-svn: 69880

llvm-svn: 69875

llvm-svn: 69873

the type assigned by sema (and is visible with sizeof(__func__) for
example) has nothing to do with what codegen ends up producing.
We should eventually add a method on PredefinedExpr to handle this.
In the meantime, just set up some framework and add some fixme's.

llvm-svn: 69872

 - Notably, there was a memory error here, SkipIvars does not have to
   be the same size as IvarsInfo.

 - Fariborz, please check.

llvm-svn: 69850

methods, class methods, and property implementations) and instead
place all of these entities into the DeclContext.

This eliminates more linear walks when looking for class or instance
methods and should make PCH (de-)serialization of ObjCDecls trivial
(and lazy).

llvm-svn: 69849

llvm-svn: 69838

Rework the shadow struct that is layed out for Objective-C classes.

 - Superclasses are now always laid out in their shadow structure at
   the first field.

 - Prior to this, the entire class heirarchy was flattened into a
   single structure which meant that alignment, padding, and bitfields
   were incorrect (the ASTRecordLayout was correct however, which
   meant our debug info didn't coincide with ivar offsets, for
   example).

 - This is still very suboptimal (for example, ivar are looked up
   recursively, but I believe the ivar layout itself is now at least
   close to correct.

 - <rdar://problem/6773388> error: objc[29823]: layout bitmap sliding
   backwards

llvm-svn: 69811

 - This is only used by CGObjCRuntime now.

llvm-svn: 69800

 - This has pros and cons, but for now the pros seem to significantly
   outway the con.

The con is that we will always need to cast in the runtime
implementation to a struct type, if we wish to access an interface
directly.

The pros are:
 - Avoid the cost of generating types which are used. Most
   manipulation of Objective-C objects is done through messages, and
   only the implementation of a class will directly access
   memory. Previously, we would convert the type even if it only
   appear as a function parameter, for example.

 - We don't need to worry about incomplete types, and
   UpdateCompletedType for interfaces is gone.

 - It becomes easier to narrow the interface to the shadow struct for
   Objective-C interfaces (so it can be eliminated).

Currently the runtimes still use the CodeGenTypes machinery to
generate the LLVM structure they need via ConvertTagDecl, but this can
eventually be replaced.

llvm-svn: 69797

underlying llvm::StructType for an interface.

llvm-svn: 69796

llvm-svn: 69793

llvm-svn: 69790

llvm-svn: 69789

 - For now, this means we are always doing the address computations by
   hand instead of constructing a proper GEP. Right now, however, this
   is less important than having fewer entry points to dealing with
   Objective-C interface layout.

llvm-svn: 69787