a memcpy to reflect that '0' has a different meaning when applied to
a load or store. Now we correctly use underaligned loads and stores for
the test case added.

llvm-svn: 165101

necessary during rewriting. As part of this, fix a real think-o here
where we might have left off an alignment specification when the address
is in fact underaligned. I haven't come up with any way to trigger this,
as there is always some other factor that reduces the alignment, but it
certainly might have been an observable bug in some way I can't think
of. This also slightly changes the strategy for placing explicit
alignments on loads and stores to only do so when the alignment does not
match that required by the ABI. This causes a few redundant alignments
to go away from test cases.

I've also added a couple of tests that really push on the alignment that
we end up with on loads and stores. More to come here as I try to fix an
underlying bug I have conjectured and produced test cases for, although
it's not clear if this bug is the one currently hitting dragonegg's
gcc47 bootstrap.

llvm-svn: 165100

more detail.

llvm-svn: 165099

llvm-svn: 165098

llvm-svn: 165097

Build ASan runtime on Linux for both x86_64 and i386, same as we do with full compiler_rt and libprofile

llvm-svn: 165096

* nullptr used to be mapped to ERROR, now mapped to nullptr
* integral was missing
* expressions now have their own error message, so they won't reach
  this. Map them to ERROR.

Note that clang usually crashes before emitting this diagnostic anyway
(see PR13984), so this change alone doesn't have an observable effect.
It makes the code more correct though.

llvm-svn: 165095

llvm-svn: 165094

This matches what's done in ItaniumMangle and makes it a bit easier
to implement mangling for more expressions. Also use the slightly nicer
"not yet implemented" error message from there.

No functionality change (except for the different error message).

llvm-svn: 165093

Remove unused function that used to get itineraries from SubTargetFeatures. This is done from MCSubTargetInfo these days.

llvm-svn: 165092

llvm-svn: 165091

llvm-svn: 165090

llvm-svn: 165089

InlineObjCInstanceMethod.m: Remove lines introduced in r165079. It broke some builds, on FreeBSD, Linux and Windows.

error: 'warning' diagnostics expected but not seen:
  Line 94: types are incompatible
1 error generated.

llvm-svn: 165088

ImportDecl's module ID was not written out and the reader accepted as module ID
the serialized:
  Record.push_back(!IdentifierLocs.empty());

llvm-svn: 165087

of a module file.

llvm-svn: 165086

llvm-svn: 165085

when an ImportDecl that was implicitly created due to an inclusion directive.

llvm-svn: 165084

llvm-svn: 165083

- General C++11 attributes were previously parsed and ignored. Now they are parsed and stored in AST.
- Add support to parse arguments of attributes that in 'gnu' namespace.
- Differentiate unknown attributes and known attributes that can't be applied to statements when emitting diagnostic.

llvm-svn: 165082

FIXME: Also cygwin?
llvm-svn: 165081

remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038> 

llvm-svn: 165080

In C++, overriding virtual methods are allowed to specify a covariant
return type -- that is, if the return type of the base method is an
object pointer type (or reference type), the overriding method's return
type can be a pointer to a subclass of the original type. The analyzer
was failing to take this into account when devirtualizing a method call,
and anything that relied on the return value having the proper type later
would crash.

In Objective-C, overriding methods are allowed to specify ANY return type,
meaning we can NEVER be sure that devirtualizing will give us a "safe"
return value. Of course, a program that does this will most likely crash
at runtime, but the analyzer at least shouldn't crash.

The solution is to check and see if the function/method being inlined is
the function that static binding would have picked. If not, check that
the return value has the same type. If the types don't match, see if we
can fix it with a derived-to-base cast (the C++ case). If we can't,
return UnknownVal to avoid crashing later.

<rdar://problem/12409977>

llvm-svn: 165079

These functions are store-agnostic, and would benefit from information in
DynamicTypeInfo but gain nothing from the store type.

No intended functionality change.

llvm-svn: 165078

Then, rename it getPointeeCXXRecordDecl and give it a nice doc comment,
and actually use it.

No intended functionality change.

llvm-svn: 165077

most of the behavior we want, but wrap the predicate in one which erases
elements from the set if they pass the predicate. Oh what I wouldn't
give for a lambda here.

Let me know if the predicate wrapping is too much magic. ;]

llvm-svn: 165076

Enable the pass by default for targets that request it, and change the
-enable-early-ifcvt to the opposite -disable-early-ifcvt.

There are still some x86 regressions when enabling early if-conversion
because of the missing machine models. Disable the pass for x86 until
machine models are added.

llvm-svn: 165075

each one separately, process a stack of MemberExpr's as a single unit so that
static calls and member access will not be warned on.

llvm-svn: 165074

preserves the values of the relocated entries, unlikely remove_if. This
allows walking them and erasing them.

Also flesh out the predicate we are using for this to support the
various constraints actually imposed on a UnaryPredicate -- without this
we can't compose it with std::not1.

Thanks to Sean Silva for the review here and noticing the issue with
std::remove_if.

llvm-svn: 165073

X86DAGToDAGISel::PreprocessISelDAG(), isel is moving load inside
callseq_start / callseq_end so it can be folded into a call. This can
create a cycle in the DAG when the call is glued to a copytoreg. We
have been lucky this hasn't caused too many issues because the pre-ra
scheduler has special handling of call sequences. However, it has
caused a crash in a specific tailcall case.

rdar://12393897

llvm-svn: 165072

This reverts 165055 and 165052 temporarily while I look at debugger
failures.

llvm-svn: 165071

llvm-svn: 165070

llvm-svn: 165069

Summary: Uses [[clang::fallthrough]] attribute in a template function, and -Wimplicit-fallthrough to check the attribute presence in an instantiation.

Reviewers: rsmith

Reviewed By: rsmith

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D55

llvm-svn: 165068

The mips 64bit instructions DSLL, DSRA, DSRL, DEXT and DINS get transformed by the assembler or through codegen direct object output to other variants based on the value of the immediate values of the operands.

If the code is generated as assembler, this transformation does not occur assuming that it will occur later in the assembler.

This code was originally called from  MipsAsmPrinter.cpp and we needed to check for OutStreamer.hasRawTextSupport(). This was not a good place for it and has been moved to MCTargetDesc/MipsMCCodeEmitter.cpp where both direct object and the assembler use it it automagically.

The test cases have been checked in for a number of weeks now.

llvm-svn: 165067

attribute going iinto XML document.

llvm-svn: 165066

scheduled for processing on the worklist eventually gets deleted while
we are processing another alloca, fixing the original test case in
PR13990.

To facilitate this, add a remove_if helper to the SetVector abstraction.
It's not easy to use the standard abstractions for this because of the
specifics of SetVectors types and implementation.

Finally, a nice small test case is included. Thanks to Benjamin for the
fantastic reduced test case here! All I had to do was delete some empty
basic blocks!

llvm-svn: 165065

also makes it more consistent with Clang and several passes' doxygen
style.

llvm-svn: 165064

llvm-svn: 165063

The new algorithm has been enabled by default for almost a week now and
seems to be stable.

llvm-svn: 165062