With -### clang return 0, so we have to use FileCheck to see if there was an
error.

llvm-svn: 191923

llvm-svn: 191921

llvm-svn: 191917

It looks like clang always produce code with the ieee comparisons, so it is
safe to ignore this flag (we still error on -mno-ieee-fp).

llvm-svn: 191912

This will emit a warning if a call to clang_analyzer_warnIfReached is
executed, printing REACHABLE. This is a more explicit way to declare
expected reachability than using clang_analyzer_eval or triggering
a bug (divide-by-zero or null dereference), and unlike the former will
work the same in inlined functions and top-level functions. Like the
other debug helpers, it is part of the debug.ExprInspection checker.

Patch by Jared Grubb!

llvm-svn: 191909

Patch by Che-Liang Chiou!

llvm-svn: 191906

Thought I'd checked that before

llvm-svn: 191901

llvm-svn: 191900

We now emit warnings when doing so and code generation is consistent
with GCC. Note that the C99 spec is unclear as to the precise
behavior.

See also ...
Bug:
  http://llvm.org/bugs/show_bug.cgi?id=16644 and

cfe-dev discussion:
  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-September/031918.html

llvm-svn: 191890

Teach TreeTransform and family how to transform generic lambdas within templates and nested within themselves.
  
This does not yet include capturing (that is next).

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130930/090048.html

When I first committed this patch - a bunch of buildbots were unable to compile the code that VS2010 seemed to compile.  Seems like there was a dependency on Sema/Template.h which VS did not seem to need, but I have now added for the other compilers.  It still compiles on Visual Studio 2010 - lets hope the buildbots remain quiet (please!)

llvm-svn: 191879

why the buildbots are failing.

llvm-svn: 191876

Teach TreeTransform and family how to transform generic lambdas within templates and nested within themselves.
  
This does not yet include capturing (that is next).

Please see test file for examples.

This patch was LGTM'd by Doug:
http://llvm-reviews.chandlerc.com/D1784

llvm-svn: 191875

An explicit cast is still needed in tbmintrin.h to convert any big integer down to i32imm.

Patch from Yunzhong Gao.

llvm-svn: 191872

enable them for distinct feature migration.
// rdar://15003157

llvm-svn: 191863

migrations under their own option. 
wip and // rdar://15003157

llvm-svn: 191855

Reviewed at http://llvm-reviews.chandlerc.com/D1795

llvm-svn: 191839

This partially addresses PR17435, but it doesn't actually implement the
pragma.  If we implement it, we should map levels 1-4 to something like
-Wall and level 0 to something like -w.

llvm-svn: 191833

llvm-svn: 191816

Also add some tests that there is actually a message and that the bug is
actually a hard error. This actually behaved correctly before, because:

- addTransition() doesn't actually add a transition if the new state is null;
  it assumes you want to propagate the predecessor forward and does nothing.
- generateSink() is called in order to emit a bug report.
- If at least one new node has been generated, the predecessor node is /not/
  propagated forward.

But now it's spelled out explicitly.

Found by Richard Mazorodze, who's working on a patch that may require this.

llvm-svn: 191805

DW_TAG_pointer_type is updated to use DITypeRef.

Paired commit with r191800.

llvm-svn: 191801

llvm-svn: 191798

Replacements were no applied when using a compilation database with paths in the
compilation command relative to the compile directory. This patch makes those
paths abosulte.

llvm-svn: 191776

This attribute allows users to use a modified C or C++ function as an ARM
exception-handling function and, with care, to successfully return control to
user-space after the issue has been dealt with.

rdar://problem/14207019

llvm-svn: 191769

llvm-svn: 191760

llvm-svn: 191758

llvm-svn: 191736

llvm-svn: 191730

When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).

See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.

[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]

llvm-svn: 191727

When we check access for lookup results, make sure we propagate the
result's access to the access control APIs; this can be different from
the natural access of the declaration depending on the path used by the lookup.

PR17394.

llvm-svn: 191726

-relaxed-aliasing.

llvm-svn: 191725

Currently, IR generation can't handle file-scope compound literals with
non-constant initializers in C++.

Fixes PR17415 (the first crash in the bug).

(We should probably change (T){1,2,3} to use the same codepath as T{1,2,3} in
C++ eventually, given that the semantics of the latter are actually defined by
the standard.)

llvm-svn: 191719

out of the working paper. This reverts r179962 and r179992.

llvm-svn: 191718

llvm-svn: 191707

Use -no-struct-path-tbaa to turn it off.

llvm-svn: 191695

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

llvm-svn: 191681

I got a bunch of buildbot failures that i don't understand - sorry.

llvm-svn: 191647

 When nested lambdas are used in NSDMI's - this prevents infinite recursion.

See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.

[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]

llvm-svn: 191645

The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization.  Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator. 

This patch has been reviewed in person both by Doug and Richard.  Richard gave me the LGTM.

A few minor changes:
  - per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
  - I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
  - Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker.  I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.

Thanks! 
 

llvm-svn: 191634

Clang uses UTF-16 and UTF-32 for its char16_t's and char32_t's
exclusively. This means that we can define __STDC_UTF_16__ and
__STDC_UTF_32__ unconditionally.

While there, define __STDC_MB_MIGHT_NEQ_WC__ for FreeBSD. FreeBSD's
wchar_t's don't encode characters as ISO-10646; the encoding depends on
the locale used. Because the character set used might not be a superset
of ASCII, we must define __STDC_MB_MIGHT_NEQ_WC__.

llvm-svn: 191631

instead, it's enabled by the -cc1 flag -fsized-deallocation, until we sort out
the backward-compatibility issues.

llvm-svn: 191629