llvm-svn: 187944

llvm-svn: 187943

llvm-svn: 187942

[objc-arc] Track if we encountered an additive overflow while computing {TopDown,BottomUp}PathCounts and do nothing if it occured.

rdar://14590914

llvm-svn: 187941

llvm-svn: 187940

Original commit message:

Stop emitting weak symbols into the "coal" sections.

The Mach-O linker has been able to support the weak-def bit on any symbol for
quite a while now. The compiler however continued to place these symbols into a
"coal" section, which required the linker to map them back to the base section
name.

Replace the sections like this:

  __TEXT/__textcoal_nt   instead use  __TEXT/__text
  __TEXT/__const_coal    instead use  __TEXT/__const
  __DATA/__datacoal_nt   instead use  __DATA/__data

<rdar://problem/14265330>

llvm-svn: 187939

llvm-svn: 187938

llvm-svn: 187937

llvm-svn: 187936

Summary: Only works for UTF-8-encoded files.

Reviewers: djasper

Reviewed By: djasper

CC: cfe-commits, klimek

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

llvm-svn: 187935

llvm-svn: 187934

llvm-svn: 187933

llvm-svn: 187932

llvm-svn: 187931

llvm-svn: 187929

llvm-svn: 187928

llvm-svn: 187927

All libm floating-point rounding functions, except for round(), had their own
ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm
adding ISD::FROUND so that round() can be custom lowered as well.

For the most part, this is straightforward. I've added an intrinsic
and a matching ISD node just like those for nearbyint() and friends. The
SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed
fround).

This will be used by the PowerPC backend in a follow-up commit.

llvm-svn: 187926

DataFlowSanitizer is a generalised dynamic data flow analysis.

Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own.  Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.

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

llvm-svn: 187925

DataFlowSanitizer is a generalised dynamic data flow analysis.

Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own.  Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.

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

llvm-svn: 187924

DataFlowSanitizer is a generalised dynamic data flow analysis.

Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own.  Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.

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

llvm-svn: 187923

llvm-svn: 187922

- Immediates can be shown as hex (either Intel or MASM style)
- See TestSettings.py for usage examples
- Verified to cause no regressions on Linux x86_64 (Ubuntu 12.10)

Patch by Richard Mitton!

llvm-svn: 187921

llvm-svn: 187920

llvm-svn: 187919

llvm-svn: 187918

llvm-svn: 187917

-fdelayed-template-parsing mode. Patch by Will Wilson!

llvm-svn: 187916

llvm-svn: 187915

The problem was that an enum without closing semicolon could be associated as a forward enum
in an erroneous declaration, leading to the identifier being associated with the enum decl but
without a declaration actually referencing it.
This resulted in not having it serialized before serializing the identifier that is associated with.

Also prevent the ASTUnit from querying the serialized DeclID for an invalid top-level decl; it may not
have been serialized.

rdar://14539667

llvm-svn: 187914

.tbss section for zerofill thread locals. Make sure we do this
before emitting the zerofills.

Fixes PR15972.

llvm-svn: 187913

llvm-svn: 187912

llvm-svn: 187911

llvm-svn: 187910

llvm-svn: 187909

Correct logic bug in find optimization for vector<bool>.  This fixes http://llvm.org/bugs/show_bug.cgi?id=16816

llvm-svn: 187908

This allows llvm-tblgen to link successfully when compiling with clang.

Both MSBuild and CMake will automatically add advapi32 as part of a set
of other dlls comprising the win32 API to the link line, but CMake
doesn't do that when compiling with clang.  Until someone adds that info
to cmake upstream, this seems like a reasonable work around.

llvm-svn: 187907

llvm-svn: 187906

llvm-svn: 187905

llvm-svn: 187904