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

Don't insert 128-bit UNDEF into 256-bit vectors. Just keep the 256-bit vector. Original patch by Elena Demikhovsky. Tweaked by me to allow possibility of covering more cases.

llvm-svn: 158792

Per Anna's comment, this is a better way to handle "to-do list"-type failures.
This way we'll know if any of the features get fixed; in an XFAIL file, /all/
the cases have to be fixed before lit would tell us anything.

llvm-svn: 158791

-stable-loops enables a new algorithm for generating the Loop
forest. It differs from the original algorithm in a few respects:

- Not determined by use-list order.
- Initially guarantees RPO order of block and subloops.
- Linear in the number of CFG edges.
- Nonrecursive.

I didn't want to change the LoopInfo API yet, so the block lists are
still inclusive. This seems strange to me, and it means that building
LoopInfo is not strictly linear, but it may not be a problem in
practice. At least the block lists start out in RPO order now. In the
future we may add an attribute or wrapper analysis that allows other
passes to assume RPO order.

The primary motivation of this work was not to optimize LoopInfo, but
to allow reproducing performance issues by decomposing the compilation
stages. I'm often unable to do this with the current LoopInfo, because
the loop tree order determines Loop pass order. Serializing the IR
tends to invert the order, which reverses the optimization order. This
makes it nearly impossible to debug interdependent loop optimizations
such as LSR.

I also believe this will provide more stable performance results across time.

llvm-svn: 158790

llvm-svn: 158789

llvm-svn: 158788

The implementation only needs inclusion from LoopInfo.cpp and
MachineLoopInfo.cpp. Clients of the interface should only include the
interface. This makes the interface readable and speeds up rebuilds
after modifying the implementation.

llvm-svn: 158787

llvm-svn: 158786

-Disable -pedantic-errors when migrating per Jordan's suggestion.
-Use llvm_move() per John's suggestion.

llvm-svn: 158785

The default global placement new just returns the pointer it is given.
Note that other custom 'new' implementations with placement args are not
guaranteed to do this.

In addition, we need to invalidate placement args, since they may be updated by
the allocator function. (Also, right now we don't properly handle the
constructor inside a CXXNewExpr, so we need to invalidate the placement args
just so that callers know something changed!)

This invalidation is not perfect because CallOrObjCMessage doesn't support
CXXNewExpr, and all of our invalidation callbacks expect that if there's no
CallOrObjCMessage, the invalidation is happening manually (e.g. by a direct
assignment) and shouldn't affect checker-specific metadata (like malloc state);
hence the malloc test case in new-fail.cpp. But region values are now
properly invalidated, at least.

The long-term solution to this problem is to rework CallOrObjCMessage into
something more general, rather than the morass of branches it is today.

<rdar://problem/11679031>

llvm-svn: 158784

[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires a cast

to something like:

[NSNumber numberWithDouble:cppb];
warning: converting to boxing syntax requires casting 'bool' to 'double'

This is way better to fully understand the warning.
rdar://11705106

llvm-svn: 158783

llvm-svn: 158782

for "hard" ARC errors, not warnings.

rdar://11691437

llvm-svn: 158781

Unbreak GCC build: GCC doesn't like clang::Parser::CommentHandler and class clang::CommentHandler to have same name.

llvm-svn: 158780

\code...\endcode, \file commands and escaing for angle brackets.

llvm-svn: 158779

llvm-svn: 158778

llvm-svn: 158777

* Escaped # and < characters in Doxygen comments as needed;
* Removed a Doxygen comment in HeaderSearch.cpp that was redundant with
  the corresponding comment in the header file.

llvm-svn: 158776

llvm-svn: 158775

* Escape < characters in Doxygen comments as needed;
* Demote one Doxygen comment to a regular comment to fix a Doxygen warning.

llvm-svn: 158774

* Escaped # characters in Doxygen comments as needed;
* Added/fixed \file and \brief markup to add summaries to Doxygen output.

llvm-svn: 158773

Also add a couple of unit tests to check the invalid-PCH error messages
to satisfy PR4568 and for the assertion (introduced in r149918 and fixed
in r158769) that would cause clang to crash when given an empty PCH.

llvm-svn: 158772

* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang

llvm-svn: 158771

Add permissions(), map_file_pages(), and unmap_file_pages() to llvm::sys::fs and add unit test. Unix is implemented.  Windows side needs to be implemented.

llvm-svn: 158770

llvm::RawMemoryObject handles empty ranges just fine, and the assert can
be triggered in the wild by e.g. invoking clang with a file that
included an empty pre-compiled header file when clang has been built
with assertions enabled. Without assertions enabled, clang will properly
report that the empty file is not a valid PCH.

llvm-svn: 158769

llvm-svn: 158768

caused a crash in an obscure case. On the plus side, it caused me to catch
another bug by inspection.

llvm-svn: 158767

When LiveIntervals is tracking fixed interference in regunits, make sure
to update those intervals as well. Currently guarded by -live-regunits.

llvm-svn: 158766

llvm-svn: 158764

llvm-svn: 158763

llvm-svn: 158762

attributes into the ThreadSafetyAttributes group, where the other
warnings currently live.

llvm-svn: 158761

Add error checking for the static qualifier which is now allowed in certain situations for OpenCL 1.2. Use the CL version to turn on this feature.
Added test case for 1.2 static storage class feature.

llvm-svn: 158759

ensureAlignment() in MachineFunction).  Also, drop setMaxAlignment() in
favor of this new function.  This creates a main entry point to setting
MaxAlignment, which will be helpful for future work.  No functionality
change intended.

llvm-svn: 158758