PR10458: Last part of providing 'auto' type specifier as an extension in C++98: permit it within type-ids.

llvm-svn: 139103

PR10458: Finesse behaviour of C++0x features when in pre-0x mode. Accept for-range and auto with an ExtWarn, and produce a -Wc++0x-compat warning in C++98 mode when auto is used as a storage class.

llvm-svn: 139102

Fix bug this uncovered.
Address minor comments from Doug.
Enable cxx_implicit_moves feature.

llvm-svn: 139101

llvm-svn: 139097

llvm-svn: 139096

llvm-svn: 139095

llvm-svn: 139094

llvm-svn: 139093

It may happen that we generate the code of a basic block from the original
scop is code generated several times. The new naming scheme reduces confusing
that earlier appeared as the version numbers of the new basic blocks could
have been interpreted as part of the name of the original basic block.

llvm-svn: 139092

Use Duncan's patch to delete the instructions in reverse order (minus the landingpad and terminator).

llvm-svn: 139090

call. The call may be in the same BB as the landingpad instruction. If that's
the case, then inserting the loads after the landingpad inst, but before the
extractvalues, causes undefined behavior.

llvm-svn: 139088

Fixes http://llvm.org/PR10826.

llvm-svn: 139087

Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.

Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.

Fixes rdar://10056932&8319466

llvm-svn: 139086

The function was only counting lines that included tokens and not empty lines,
but MaxLines (mainly initiated to the line where the code-completion point resides)
is a count of overall lines (even empty ones).

llvm-svn: 139085

llvm-svn: 139084

llvm-svn: 139080

llvm-svn: 139079

llvm-svn: 139078

well.

Also, clean up the flow of the code a bit, and factor things more
nicely.

Finally, add the test case that was missing from my previous
commit (sorry), with new tests added to cover temporaries and other fun
cases.

llvm-svn: 139077

values that the resume instruction uses.
PR10850

llvm-svn: 139076

reference members of classes. We've had several bugs reported because of
this, and there's no reason not to flag it right away in the compiler.

Comments especially welcome on the strategy for implementing this
warning (IE, what should trigger this?) and on the text of the warning
itself.

I'm going to extend this to cover obvious cases with temporaries and
beef up the test cases some in subsequent patches. I'll then run it over
a large codebase and make sure its not misbehaving before I add it to
-Wall or turn it on by default. I think this one might be a good
candidate for on by default.

llvm-svn: 139075

llvm-svn: 139074

the cycle of missing AVX counterparts of already present SSE* patterns

llvm-svn: 139073

llvm-svn: 139072

llvm-svn: 139071

llvm-svn: 139070

llvm-svn: 139069

duplicate it for AVX mode.

llvm-svn: 139068

llvm-svn: 139067

that the AVX versions (even the 128-bit ones) all clear the upper part
of the destination register.

llvm-svn: 139066

pattern should be matched

llvm-svn: 139065

llvm-svn: 139064

it!

llvm-svn: 139063

llvm-svn: 139062

llvm-svn: 139061

OptForSize pattern

llvm-svn: 139060

If we have a chain of zext -> assert_zext -> zext -> use, the first zext would get simplified away because of the later zext, and then the later zext would get simplified away because of the assert.  The solution is to teach SimplifyDemandedBits that assert_zext demands all of the high bits of its input, rather than only those demanded by its users.  No testcase because the only example I have manifests as llvm-gcc miscompiling LLVM, and I haven't found a smaller case that reproduces this problem.
Fixes <rdar://problem/10063365>.

llvm-svn: 139059

llvm-svn: 139058

The explanation about a 0 argument being materialized as xor is no
longer valid.  Rematerialization will check if EFLAGS is live before
clobbering it.

The code produced by X86TargetLowering::EmitLoweredSelect does not
clobber EFLAGS.

This causes one less testb instruction to be generated in the cmov.ll
test case.

llvm-svn: 139057

It is only allowed to clobber EFLAGS at the end of a block if it isn't
live-in to any successor.

llvm-svn: 139056