llvm-svn: 187972

'-fno-unroll-loops'. The option to the backend is even called
'DisableUnrollLoops'. This is precisely the form that Clang *didn't*
support. We didn't recognize the flag, we didn't pass it to the CC1
layer, and even if we did we wouldn't use it. Clang only inspected the
positive form of the flag, and only did so to enable loop unrolling when
the optimization level wasn't high enough. This only occurs for an
optimization level that even has a chance of running the loop unroller
when optimizing for size.

This commit wires up the 'no' variant, and switches the code to actually
follow the standard flag pattern of using the last flag and allowing
a flag in either direction to override the default.

I think this is still wrong. I don't know why we disable the loop
unroller entirely *from Clang* when optimizing for size, as the loop
unrolling pass *already has special logic* for the case where the
function is attributed as optimized for size! We should really be
trusting that. Maybe in a follow-up patch, I don't really want to change
behavior here.

llvm-svn: 187969

so that it can be toggled independently of other deprecated warnings.

llvm-svn: 187958

It broke a public build bot.

llvm-svn: 187957

Fixes PR16394.

llvm-svn: 187955

llvm-svn: 187952

llvm-svn: 187951

Summary:
UBSan was checking for alignment of the derived class on the pointer to
the base class, before converting. With some class hierarchies, this could
generate false positives.

Added test-case.

llvm-svn: 187948

These flags set some preprocessor macros and injects a dependency
on the runtime library into the object file, which later is picked up
by the linker.

This also adds a new CC1 flag for adding a dependent library.

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

llvm-svn: 187945

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

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

llvm-svn: 187922

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

llvm-svn: 187916

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

In particular, left braces after an enum declaration now occur on their
own line.  Further, when short ifs/whiles are allowed these no longer
cause the left brace to be on the same line as the if/while when a
brace is included.

Patch by Thomas Gibson-Robinson.

llvm-svn: 187901

Before this patch we would align

long long int big[1024];

to 4 bytes on 32 bit systems. The problem is that we were only looking
at the element type when getLargeArrayMinWidth returned non zero.

llvm-svn: 187897

// rdar://14258334

llvm-svn: 187893

Before:
  #pragma omp reduction( | : var)
After:
  #pragma omp reduction(| : var)

llvm-svn: 187892

This field is just IsDefaulted && !IsDeleted; in all places it's used,
a simple check for isDefaulted() is superior anyway, and we were forgetting
to set it in a few cases.

Also eliminate CXXDestructorDecl::IsImplicitlyDefined, for the same reasons.

No intended functionality change.

llvm-svn: 187891

Patch by David Wiberg.

llvm-svn: 187888

llvm-svn: 187871

This removes a formatting choice that was added at one point, but is
not generally liked by users. Specifically, in builder-type calls, do
(easily) break if the object before the ./-> is either a field or a
parameter-less function call. I.e., don't break after "aa.aa.aa" or
"aa.aa.aa()". In general, these sequences in builder-type calls are
seen as a single entity and thus breaking them up is a bad idea.

llvm-svn: 187865

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

llvm-svn: 187840

// rdar://14258334

llvm-svn: 187835

This implements support for the /Fo option, which is used
to set the filename or output dir for object files.

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

llvm-svn: 187820

decrements inside for loops.  Idea for this warning proposed in PR15636:

http://llvm.org/bugs/show_bug.cgi?id=15636

llvm-svn: 187817

on @property migration. Don't set unsafe_unretained
on non-object properties. Set 'retain' on strong
properties. Makecertain properties with specific
names unsafe_unretained as well.

llvm-svn: 187810

llvm-svn: 187785

llvm-svn: 187784

expression, truncate the stored value to the size of the bitfield.

llvm-svn: 187782

Removed hack that was used to properly restore the nested name specifier of qualified variable template ids. It turns out that the current implementation was just not logical setup for it. This commit has made it so.

llvm-svn: 187776

Fixing commit r187768: Moved diagnosis of forward declarations of variable templates from Parser to Sema.

llvm-svn: 187770

comparing non-reference function parameters.  The qualifiers don't matter for
comparisons.

llvm-svn: 187769

llvm-svn: 187768

I met a message, "fatal error: file 'nul' modified since it was first processed".

llvm-svn: 187767

FIXME: Would '0' be an appropriate value in SequenceNumber?
llvm-svn: 187766

llvm-svn: 187765

Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...

llvm-svn: 187762

These are used to specify source files, and whether to treat source
files as C or C++.

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

llvm-svn: 187760

There were three things missing from the original implementation:

- We would omit the 'E' qualifier for members int 64-bit mode.
- We would not exmaine the qualifiers in 'IsMember' mode.
- We didn't generate the correct backref to the base class.

llvm-svn: 187753