llvm-svn: 59371

Introduce a single AST node SizeOfAlignOfExpr for all sizeof and alignof expressions, both of values and types.

llvm-svn: 59057

t.c:1:13: error: cannot codegen this designators yet
int a[10] = {2, 4, [8]=9, 10};
            ^~~~~~~~~~~~~~~~~

llvm-svn: 58220

llvm-svn: 57909

llvm-svn: 57392

constant lvalue.  Implement this in codegen by moving the code out of CGBuiltin
into EmitConstantExpr.

llvm-svn: 57163

constants for them, just use the constant evaluator to do the job.  This
also fixes crashes on 'unknown constant builtins'.

llvm-svn: 57155

llvm-svn: 55299

llvm-svn: 55249

Add ExplicitCastExpr to replace the current CastExpr, and have ImplicitCastExpr and ExplicitCastExpr derive from a common base class (CastExpr):

Expr
  -> CastExpr
     -> ExplicitCastExpr
     -> ImplicitCastExpr 

llvm-svn: 54955

llvm-svn: 54837

 - We are beyond the point where this shows up often and when it does
   generating miscompiled files is bad.

llvm-svn: 54836

 - Returns addr of constant for argument + '\0'.
 - I couldn't think of a better name.
 - Move appropriate users of GetAddrOfConstantString to this.

Rename getStringForStringLiteral to GetStringForStringLiteral.

Add GetAddrOfConstantStringFromLiteral
 - This combines GetAddrOfConstantString and
   GetStringForStringLiteral. This method can be, but is not yet, more
   efficient.

Change GetAddrOfConstantString to not add terminating '\0'
 - <rdar://problem/6140956>

llvm-svn: 54768

    ObjCProtocolDecl directly.

Implement CodeGen support for forward protocol decls (no-ops are so
    nice to implement).

Also moved CGObjCRuntime.h out of CodeGenModule.h

llvm-svn: 54709

Changed CGObjCRuntime::GenerateConstantString interface to take
       std::string instead of char* and size.

Change ObjC functions which call on GenerateConstantString to bitcast
       result to appropriate type.

llvm-svn: 54659

 - Changed CodeGenModule::getObjCRuntime to return reference.
 - Added CodeGenModule::hasObjCRuntime predicate.

llvm-svn: 54645

 - Remove internal uses of AST.h

llvm-svn: 54628

  temporarily, I assumed GetAddrForConstantString literal was being
  used consistently but it doesn't look like it is.

Factored out a CodeGenModule::getStringForStringLiteral which handles
  extracting a std::string for the bytes of a StringLiteral, padded to
  match the type.

Update EmitLValue to use getStringForStringLiteral, this was
  previously not padding strings correctly. Good thing we only emit
  strings in 4 different places!

llvm-svn: 54621

  length element.

Fix some 80-col violations.

llvm-svn: 54610

Finally fix PR2189.  This makes a fairly invasive but important change to
move getAsArrayType into ASTContext instead of being a method on type.
This is required because getAsArrayType(const AT), where AT is a typedef
for "int[10]" needs to return ArrayType(const int, 10).

Fixing this greatly simplifies getArrayDecayedType, which is a good sign.

llvm-svn: 54317

 - No (intended) functionality change.

 - Primary purpose is to clearly separate (lazy) construction of
   globals that are a forward declaration or tentative definition from
   those that are the final definition.

 - Lazy construction is now encapsulated in
   GetAddrOf{Function,GlobalVar} while final definitions are
   constructed in EmitGlobal{Function,Var}Definition.
 
 - External interface for dealing with globals is now limited to
   EmitGlobal and GetAddrOf{Function,GlobalVar}.

 - Also updated helper functions dealing with statics, annotations,
   and ctors to be private.

llvm-svn: 54179

llvm-svn: 54108

llvm-svn: 54107

<rdar://problem/6078606>

llvm-svn: 53737

"this patch adds code generation hooks for Objective-C constant strings.  It also modifies Sema so that Objective-C constant strings are treated as untyped objects if the interface for the constant string class can not be found.  This is consistent with Apple GCC.  I thought it was consistent with GNU GCC, since this was causing failures when trying to compile GNUstep with (GNU) GCC, but it appears that this is not the case when attempting to produce a simple test case to demonstrate it.  Possibly there is a way of making the error go away, but I haven't found out what it is yet."

Patch by David Chisnall!

llvm-svn: 52599

reported on cfe-dev by Cédric Venet.

Note that I seriously doubt that this perticular construct is useful, 
though: it's a pointer in an alternate address space pointing into 
unqualified address space.

llvm-svn: 52076

PR2419.

llvm-svn: 52060

llvm-svn: 52049

llvm-svn: 51838

this does is reconstruct the type for structs and arrays if the type 
wouldn't be compatible otherwise.

The assertion about packing in the struct type reconstruction code 
sucks, but I don't see any obvious way to fix it.  Maybe we need a general
utility method to take a list of types and alignments and try to construct an
unpacked type if possible?

llvm-svn: 51785

of elements.

llvm-svn: 51769

bit-field initialization; ugly code, X86-only, but it works, at least 
for basic stuff.  Separates/adds union initialization; currently disabled,
though, because the struct/array code needs modifications to support 
elements of the wrong type.

Fixes PR2381 and PR2309 with the bit-field initialization.  And NetHack 
compiles and appears to work with a few tweaks (to work around the lack 
of transparent_union support, and clang being a bit strict about
conflicting declarations).

llvm-svn: 51763

constant expressions.

llvm-svn: 51682

expressions.

llvm-svn: 51677

implement bitfield codegen (although I don't envy the person who 
implements it).  This also prevents a crash on code like that from PR2309
(it's still broken, but it fails more gracefully).

llvm-svn: 51285

llvm-svn: 51284

llvm-svn: 49979

Remove FileVarDecl and BlockVarDecl. They are replaced by VarDecl::isBlockVarDecl() and VarDecl::isFileVarDecl().

This is a fairly mechanical/large change. As a result, I avoided making any changes/simplifications that weren't directly related. I did break two Analysis tests. I also have a couple FIXME's in UninitializedValues.cpp. Ted, can you take a look? If the bug isn't obvious, I am happy to dig in and fix it (since I broke it).

llvm-svn: 49748

interaction for function parameters, fixing PR2046.

Patch by Doug Gregor!

llvm-svn: 49369

lib dir and move all the libraries into it.  This follows the main
llvm tree, and allows the libraries to be built in parallel.  The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in.  This speeds
up parallel builds, particularly incremental ones.

llvm-svn: 48402