Add users of a MERGE_VALUE node to the worklist to process again when the node is removed.  Sorry, no test case.  Foudn it by inspection of the code

llvm-svn: 158839

llvm-svn: 158837

It's very easy for anonymous external linkage to propagate in C++ through
return types and parameter types. Likewise, it's possible that a template
containing an inline function is only used with parameters that have internal
linkage. Actually diagnosing where the internal linkage comes from is fairly
difficult (both to locate and then to print nicely). Finally, since we only
have one translation unit available, we can't even prove that any of this
violates the ODR.

This warning needs better-defined behavior in C++ before it can really go in.

Rewording of the C warning (which /is/ specified by C99) coming shortly.

llvm-svn: 158836

error was asserting on anything that included Windows.h.  MS-style inline asm is
still dropped, but at least now we're not completely silent about it.

llvm-svn: 158833

CreateEnumType doesn't participate in caching so the descriptor for the enum
gets recomputed for every reference of an element of an enum, only to get
discarded when it gets turned into an MDNode.

No functionality change except performance.

llvm-svn: 158832

Regunit live ranges are computed on demand, so when mi-sched calls
handleMove, some regunits may not have live ranges yet.

That makes updating them easier: Just skip the non-existing ranges. They
will be computed correctly from the rescheduled machine code when they
are needed.

llvm-svn: 158831

llvm-svn: 158830

replace usage of EmitGEPOffset() with TargetData::getIndexedOffset() when the GEP offset is known to be constant.
With this change, we avoid relying on the IR Builder to constant fold the operations.

No functionality change intended.

llvm-svn: 158829

change in behavior. // rdar://11671080

llvm-svn: 158828

llvm-svn: 158827

Rose and Richard Smith for catching these.

llvm-svn: 158826

llvm-svn: 158823

The test case for this will come with the PPC indexed preinc loads commit.

llvm-svn: 158822

llvm-svn: 158821

llvm-svn: 158820

llvm-svn: 158819

llvm-svn: 158818

llvm-svn: 158817

llvm-svn: 158816

llvm-svn: 158815

llvm-svn: 158814

llvm-svn: 158813

to get it working again, two changes were needed:

- I had to give up on glob-based file expansion. This just isn't well
  supported by CMake, and until we convince upstream there of its value,
  it's not worth dealing with the pain.
- Add the common library as otherwise even ASan won't build.

This now builds again, although the "correctness" of it is a touch
debatable. ;] Specifically, there is no merging of the common runtime
library with the asan runtime library into a single archive file. I'm
not really sure what the best technique is for that, and it may be
influenced by the ongoing discussion about how best to link runtime
libraries.

Note of course that this is still very much WIP. It doesn't entirely
work yet, and remains disabled by the LLVM projects/CMakeLists.txt until
it is in a working state.

llvm-svn: 158811

llvm-svn: 158810

Adds a utility class method to TestBase that checks and removes a temp
file.
Removed every use of system() to execute rm -f.

llvm-svn: 158809

llvm-svn: 158808

That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.

However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.

It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?

Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.

llvm-svn: 158807

llvm-svn: 158806

llvm-svn: 158805

llvm-svn: 158804

llvm-svn: 158803

This issue was caught by the new '-Winternal-linkage-in-inline' warning.

llvm-svn: 158801

There is a pretty staggering amount of this in LLVM's header files, this
is not all of the instances I'm afraid. These include all of the
functions that (in my build) are used by a non-static inline (or
external) function. Specifically, these issues were caught by the new
'-Winternal-linkage-in-inline' warning.

I'll try to just clean up the remainder of the clearly redundant "static
inline" cases on functions (not methods!) defined within headers if
I can do so in a reliable way.

There were even several cases of a missing 'inline' altogether, or my
personal favorite "static bool inline". Go figure. ;]

llvm-svn: 158800

I'll admit I'm not entirely satisfied with this change, but it seemed
the cleanest option. Other suggestions quite welcome

The issue is that the traits specializations have static methods which
return the typedef'ed PHI_iterator type. In both the IR and MI layers
this is typedef'ed to a custom iterator class defined in an anonymous
namespace giving the types and the functions returning them internal
linkage. However, because the traits specialization is defined in the
'llvm' namespace (where it has to be, specialized template lives there),
and is in turn used in the templated implementation of the SSAUpdater.
This led to the linkage conflict that Clang now warns about.

The simplest solution to me was just to define the PHI_iterator as
a nested class inside the trait specialization. That way it still
doesn't get scoped widely, it can't be accidentally reused somewhere,
etc. This is a little gross just because nested class definitions are
a little gross, but the alternatives seem more ad-hoc.

llvm-svn: 158799

The TEST_F macros actually declare *subclasses* of the test fixtures.
Even if they didn't we don't want them to declare external functions.
The entire unit test, including both the fixture class and the fixture
test cases should be wrapped in the anonymous namespace.

This issue was caught by the new '-Winternal-linkage-in-inline' warning.

llvm-svn: 158798

llvm-svn: 158797

a bit further.  We may wish to just have -Wno flags to silence warnings, and not have a -no-pedantic.

llvm-svn: 158796

llvm-svn: 158795

../tools/clang/lib/Serialization/ASTReader.cpp:6316:9: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]

Also fix the indentation here to match the coding conventions.

llvm-svn: 158794

target Objective-C runtime down to the frontend:  break this
down into a single target runtime kind and version, and compute
all the relevant information from that.  This makes it
relatively painless to add support for new runtimes to the
compiler.  Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime.  This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.

As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.

I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.

llvm-svn: 158793