which is: { <4 x float>, <4 x float> } should continue to go through memory.

llvm-svn: 134946

people write useful cleanup classes.

llvm-svn: 134942

specified, 128 avx code is used and we're not sure yet if this the behavior
we want (and if it does, some improvements are needed before relying on it).

llvm-svn: 134939

Patch by Caitlin Sadowski.

llvm-svn: 134938

into a static helper.

Original patch by Caitlin Sadowski, style tweaks by me.

llvm-svn: 134937

llvm-svn: 134935

add one more testcase.

llvm-svn: 134934

llvm-svn: 134932

llvm-svn: 134926

llvm-svn: 134919

llvm-svn: 134913

require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.

llvm-svn: 134906

When two different types has the same text representation in the same
diagnostic message, print an a.k.a. after the type if the a.k.a. gives extra
information about the type.

class versa_string;

typedef versa_string string;

namespace std {template <typename T> class vector;}

using std::vector;

void f(vector<string> v);

namespace std {
class basic_string;
typedef basic_string string;
template <typename T> class vector {};
void g() {
  vector<string> v;
  f(v);
}
}

Old message:
----------------
test.cc:15:3: error: no matching function for call to 'f'
  f(&v);
  ^
test.cc:7:6: note: candidate function not viable: no known conversion from
      'vector<string>' to 'vector<string>' for 1st argument
void f(vector<string> v);
     ^
1 error generated.

New message:
---------------
test.cc:15:3: error: no matching function for call to 'f'
  f(v);
  ^
test.cc:7:6: note: candidate function not viable: no known conversion from
      'vector<string>' (aka 'std::vector<std::basic_string>') to
      'vector<string>' (aka 'std::vector<versa_string>') for 1st argument
void f(vector<string> v);
     ^
1 error generated.

llvm-svn: 134904

functions. Fixes <rdar://problem/9731999>.

llvm-svn: 134897

llvm-svn: 134893

llvm-svn: 134892

 - an off-by-one error in emission of irregular array limits for
   InitListExprs
 - use an EH partial-destruction cleanup within the normal
   array-destruction cleanup
 - get the branch destinations right for the empty check
Also some refactoring which unfortunately obscures these changes.

llvm-svn: 134890

llvm-svn: 134888

llvm-svn: 134880

llvm-svn: 134876

llvm-svn: 134875

is called whenever a tag type is completed.  We previously used that
as the sign to layout the codegen representation for the tag type,
which worked but meant that we laid out *every* completed type, whether
it was used or not.

Now we just lay out the type if we've already seen it somehow else.
This means that we lay out types we've used but haven't seen a body
for, but we don't lay out tons of stuff that noone cares about.

llvm-svn: 134866

us to revert the other half of r134860.  Now things are back to a relatively tidy state.

llvm-svn: 134865

llvm-svn: 134864

caused us to skip layout out a function accurately.  If
so, flush the type cache for both the function and struct
case to ensure that any pointers to the functions get
recomputed.  This is overconservative, but with this patch
clang can build itself again.

llvm-svn: 134863

type, even when in the struct case.  This was one root issue that was
causing type mismatches throughout the compiler.

llvm-svn: 134862

conservative when converting a functiontype to IR when in a "pointer within
a struct" context.  This has the unfortunate sideeffect of compiling all 
function pointers inside of structs into "{}*" which, though correct, is
ugly.  This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.

llvm-svn: 134861

do an explicit bitcast to whatever ConvertType produces.  This will
go with the next patch.

llvm-svn: 134860

llvm-svn: 134855

it is a predicate, not an action.  Change the return type to be a bool,
not the incomplete member.  Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:

struct T {
 struct T (*p)(void);
} t;

into:

%struct.T = type { {}* }

@t = common global %struct.T zeroinitializer, align 8

llvm-svn: 134853

This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.

<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.

Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.

Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.

rdar://9735086.

llvm-svn: 134844

the enum has already been converted.  If not, there cannot be any types
built on top of it, so there is no need to flush the cache.

llvm-svn: 134841

llvm-svn: 134831

expecting so much concentrated oddity on what seemed like a
trivial feature.  Thanks to François Pichet for doing the
MSVC legwork here.

llvm-svn: 134813

llvm-svn: 134785

  - Emit default-initialization of arrays that were partially initialized
    with initializer lists with a loop, rather than emitting the default
    initializer N times;
  - support destroying VLAs of non-trivial type, although this is not
    yet exposed to users; and
  - support the partial destruction of arrays initialized with
    initializer lists when an initializer throws an exception.

llvm-svn: 134784

Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.

clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.

<rdar://problem/9694837>

llvm-svn: 134770

llvm-svn: 134765

llvm-svn: 134761

llvm-svn: 134754