My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer.  This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.

llvm-svn: 170034

We don't handle array destructors correctly yet, but we now apply the same
hack (explicitly destroy the first element, implicitly invalidate the rest)
for multidimensional arrays that we already use for linear arrays.

<rdar://problem/12858542>

llvm-svn: 170000

call sites as tail calls unconditionally.  While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug.  See r169796 for the llvm/fast-isel side of things.
rdar://12553082

llvm-svn: 169996

Don't warn about disabled macro expansion if we see the name of a function-like macro which isn't immediately followed by '('. FreeBSD's stdio.h #defines foo(x) to (foo)(x), apparently.

llvm-svn: 169960

even if the directive is inside a declaration.

Fixes rdar://11548788 & http://llvm.org/PR12970

llvm-svn: 169949

llvm-svn: 169947

"ansi-escape-sequences" is easy convenient to exclude win32. Please be patient.

llvm-svn: 169945

llvm-svn: 169923

llvm-svn: 169922

latter is rather a mess to type.

llvm-svn: 169919

llvm-svn: 169917

Add -fslp-vectorize (with -ftree-slp-vectorize as an alias for gcc compatibility)
to provide a way to enable the basic-block vectorization pass. This uses the same
acronym as gcc, superword-level parallelism (SLP), also common in the literature,
to refer to basic-block vectorization.

Nadav suggested this as a follow-up to the adding of -fvectorize.

llvm-svn: 169909

byref variable requires extended layout info. to prevent 
a crash involving arrays declared __block. // rdar://12787751

llvm-svn: 169908

unavailable due to availability attributes. <rdar://problem/12798237>

llvm-svn: 169903

compatibility with gcc.
rdar://12839978 

llvm-svn: 169888

rdar://12839978 

llvm-svn: 169885

Sorry for my 3rd commit :(

llvm-svn: 169827

clang/test/Driver/debug-options-as.c: Fixup not to use prefix=S. I didn't know "REQUIRES:" would match --check-prefix=S ...

llvm-svn: 169826

It is not set at targetting cygming. See PR12920.

llvm-svn: 169824

We don't want to relax all instructions in

$ clang -c test.s

since most users don't pass -O when using the driver to assemble.

On the other hand, -save-temps should not change the output unnecessary, so in

$ clang -c test.c -save-temps

we should relax all instructions.

llvm-svn: 169815

definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.

llvm-svn: 169805

inlined.

Fixes a false positive that occurs if a user writes their own
initWithBytesNoCopy:freeWhenDone wrapper.

llvm-svn: 169795

llvm-svn: 169778

llvm-svn: 169768

Also, add the -S option.

llvm-svn: 169763

was #import'ed.

llvm-svn: 169761

This prevents the functions generated by that pass from using the red zone.
<rdar://problem/12843084>

llvm-svn: 169755

llvm-svn: 169743

llvm-svn: 169705

llvm-svn: 169696

both LE and BE targets.

AFAICT, Clang get's this correct for PPC64. I've compared it to GCC 4.8
output for PPC64 (thanks Roman!) and to my limited ability to read power
assembly, it looks functionally equivalent. It would be really good to
fill in the assertions on this test case for x86-32, PPC32, ARM, etc.,
but I've reached the limit of my time and energy... Hopefully other
folks can chip in as it would be good to have this in place to test any
subsequent changes.

To those who care about PPC64 performance, a side note: there is some
*obnoxiously* bad code generated for these test cases. It would be worth
someone's time to sit down and teach the PPC backend to pattern match
these IR constructs better. It appears that things like '(shr %foo,
<imm>)' turn into 'rldicl R, R, 64-<imm>, <imm>' or some such. They
don't even get combined with other 'rldicl' instructions *immediately
adjacent*. I'll add a couple of these patterns to the README, but
I think it would be better to look at all the patterns produced by this
and other bitfield access code, and systematically build up a collection
of patterns that efficiently reduce them to the minimal code.

llvm-svn: 169693

This was an egregious bug due to the several iterations of refactorings
that took place. Size no longer meant what it original did by the time
I finished, but this line of code never got updated. Unfortunately we
had essentially zero tests for this in the regression test suite. =[

I've added a PPC64 run over the bitfield test case I've been primarily
using. I'm still looking at adding more tests and making sure this is
the *correct* bitfield access code on PPC64 linux, but it looks pretty
close to me, and it is *worlds* better than before this patch as it no
longer asserts! =] More commits to follow with at least additional tests
and maybe more fixes.

Sorry for the long breakage due to this....

llvm-svn: 169691

array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.

llvm-svn: 169690

don't mark the function as invalid, since we suppress the error.

llvm-svn: 169689

llvm-svn: 169688

Escape % in the TextDiagnosticBuffer so they aren't interpreted twice when fed into the diagnostic formatting machinery again.

Fixes PR14543.

llvm-svn: 169677

Linux too, as I think we inherited it from there.  The ABI spec says 128-bit,
although I think SGI's compiler on IRIX may be the only thing ever to support
this.

llvm-svn: 169674

the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.

In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.

As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):

struct A { template<typename T> A(T &); };
struct B { mutable A a; };

llvm-svn: 169673

llvm-svn: 169669

Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.

This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.

This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.

llvm-svn: 169667