llvm-svn: 147471

llvm-svn: 147470

llvm-svn: 147469

which should not be default synthesized.

llvm-svn: 147468

modules. This leaves us without an explicit syntax for importing
modules in C/C++, because such a syntax needs to be discussed
first. In Objective-C/Objective-C++, the @import syntax is used to
import modules.

Note that, under -fmodules, C/C++ programs can import modules via the
#include mechanism when a module map is in place for that header. This
allows us to work with modules in C/C++ without committing to a syntax.

llvm-svn: 147467

preprocessor to warn about it.

llvm-svn: 147466

If anybody has strong feelings about 'default: assert(0 && "blah")' vs
'default: llvm_unreachable("blah")', feel free to regularize the instances of
each in this file.

llvm-svn: 147459

Patch provided by Ed Schouten!

llvm-svn: 147458

attributes for later use.

llvm-svn: 147457

llvm-svn: 147456

to make a macro public (the default for headers) or private,
respectively.

llvm-svn: 147455

llvm-svn: 147454

llvm-svn: 147453

  @import identifier [. identifier]* ;

llvm-svn: 147452

declarations in the AST unless modules are enabled. This case doesn't
come up with precompiled headers, and it isn't cheap.

llvm-svn: 147451

member function template, since the behavior is identical for
ObjCInterfaceDecl and ObjCProtocolDecl. It's expected that all
redeclarable entities will have the same behavior.

llvm-svn: 147450

llvm-svn: 147449

"AutoModuleImport" preprocessor option and is tied to -fmodules.

llvm-svn: 147448

module imports from -fauto-module-import to -fmodules. The new name
will eventually be used to enable modules, and the #include/#import
mapping is a crucial part of the feature.

llvm-svn: 147447

llvm-svn: 147446

The failure seen on win32, when i64 type is illegal.
It happens on stage of conversion VECTOR_SHUFFLE to BUILD_VECTOR.

The failure message is:
llc: SelectionDAG.cpp:784: void VerifyNodeCommon(llvm::SDNode*): Assertion `(I->getValueType() == EltVT || (EltVT.isInteger() && I->getValueType().isInteger() && EltVT.bitsLE(I->getValueType()))) && "Wrong operand type!"' failed.

I added a special test that checks vector shuffle on win32.

llvm-svn: 147445

llvm-svn: 147444

llvm-svn: 147443

- Add the LLVM Developer Meeting 2012 talk
- Add papers used within Polly and papers interesting to read in general

llvm-svn: 147442

llvm-svn: 147441

-ffast-math.

llvm-svn: 147440

"phony" insertion point.

Fixes rdar://10619599: "SelectionDAGBuilder shouldn't visit PHI nodes!" assert

llvm-svn: 147439

Add a test that such characters don't make it through to StringLiteral objects
in error recovery.

llvm-svn: 147438

1.  Fix make_shared<const T>.  2.  Allow allocator<const T> as an extension.  3.  Refactor work which fixed unique_ptr<const T[]>.  4.  Remove no-longer-needed private declarations from unique_ptr.  5.  Add constraints to some shared_ptr and weak_ptr constructors and assignment operators so that is_constructible/is_assignable give the correct answers for shared_ptr and weak_ptr.  6.  Make defensive preparations in the shared_ptr free functions for the introduction of shared_ptr<T[]> in the future.  7.  As an optimization, add move constructor and move assignment to weak_ptr.

llvm-svn: 147437

is known (to Clang), but is not visible because the module has not yet
been imported.

llvm-svn: 147436

llvm-svn: 147435

Clang driver. This involves a bunch of silly option parsing code to try
to carefully emulate GCC's options. Currently, this takes a conservative
approach, and unless all of the unsafe optimizations are enabled, none
of them are. The fine grained control doesn't seem particularly useful.
If it ever becomes useful, we can add that to LLVM first, and then
expose it here.

This also fixes a few tiny bugs in the flag management around
-fhonor-infinities and -fhonor-nans; the flags now form proper sets both
for enabling and disabling, with the last flag winning.

I've also implemented a moderately terrifying GCC feature where
a language change is also provided by the '-ffast-math' flag by defining
the __FAST_MATH__ preprocessor macro. This feature is tracked and
serialized in the frontend but it isn't used yet. A subsequent patch
will add the preprocessor macro and tests for it.

I've manually tested that codegen appears to respect this, but I've not
dug in enough to see if there is an easy way to test codegen options w/o
relying on the particulars of LLVM's optimizations.

llvm-svn: 147434

llvm-svn: 147433

is testing the bitcode reader's functionality, not VMCore's. Add the
what is a hope sufficient build system mojo to build and run a new
unittest.

Also clean up some of the test's naming. The goal for the file should be
to unittest the Bitcode Reader, and this is just one particular test
among potentially many in the future. Also, reverse my position and
relegate the PR# to a comment, but stash the comment on the same line as
the test name so it doesn't get lost. This makes the code more
self-documenting hopefully w/o losing track of the PR number.

llvm-svn: 147431

Miscellaneous shuffle lowering cleanup. No functional changes. Primarily converting the indexing loops to unsigned to be consistent across functions.

llvm-svn: 147430

Make CanXFormVExtractWithShuffleIntoLoad reject loads with multiple uses. Also make it return false if there's not even a load at all. This makes the code better match the code in DAGCombiner that it tries to match. These two changes prevent some cases where vector_shuffles were making it to instruction selection and causing the older shuffle selection code to be triggered. Also needed to fix a bad pattern that this change exposed. This is the first step towards getting rid of the old shuffle selection support. No test cases yet because there's no way to tell whether a shuffle was handled in the legalize stage or at instruction selection.

llvm-svn: 147428

build. This didn't show up in the CMake build because the CMake build
for the unittests is rather poorly factored.

This probably isn't the correct fix. This should be a bitcode reader
unittest not a VMCore unittest. I'll move it and clean various parts of
the unittest up in a follow-up patch, but I wanted to unbreak the bots.

llvm-svn: 147427

Optimize the sequence blend(sign_extend(x)) to blend(shl(x)) since SSE blend instructions only look at the highest bit.

llvm-svn: 147426

PR11677.

llvm-svn: 147425

llvm-svn: 147424