Now that the libcpp implementations of these methods has a branch that doesn't call
memmove(), the analyzer needs to invalidate the destination for these methods explicitly.

rdar://problem/23575656

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260043 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices."

This reverts commit r259985, as it still fails one buildbot.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260036 91177308-0d34-0410-b5e6-96231b3b80d8

This helps when trying to debug who inserted into Replacements.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260028 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260020 91177308-0d34-0410-b5e6-96231b3b80d8

Adjust the driver to invoke the linker more similar to gcc.  -dynamic-linker is
only passed if -static and -shared are not part of the compiler (driver)
invocation.  Replicate the passing of -export-rdynamic as per the GCC link spec:

  %{!static: %{rdynamic:-export-dynamic} %{!shared:-dynamic-linker ...}}

This behaviour is consistent across all the targets that are supported, so no
need to conditionalise it on the target.

Resolves PR24245.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260019 91177308-0d34-0410-b5e6-96231b3b80d8

The ivar ref would be transformed by the Typo Correction TreeTransform, but not
be owned, resulting in the source location being invalid.  This would eventually
lead to an assertion in findCapturingExpr.  Prevent this assertion from
triggering.

Resolves PR25113.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260017 91177308-0d34-0410-b5e6-96231b3b80d8

We would previously assert in findCapturingExpr when performing a typo
correction resulting in an assignment of an ObjC property with a strong lifetype
specifier due to the expression not being rooted in the file (invalid SLoc)
during the retain cycle check on the typo-corrected expression.  Handle the
expression type appropriately during the TreeTransform to ensure that we have a
source location associated with the expression.

Fixes PR26486.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260016 91177308-0d34-0410-b5e6-96231b3b80d8

Follow-up to r259975. Kudos to the ASAN bots!

<rdar://problem/24493203>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260002 91177308-0d34-0410-b5e6-96231b3b80d8

It is common for the ivars for read-only assign properties to always be stored retained,
so don't warn for a release in dealloc for the ivar backing these properties.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259998 91177308-0d34-0410-b5e6-96231b3b80d8

Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259985 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

It triggered some problem in the configuration related with zlib and exposed in the driver.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259984 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation. 

This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it.

In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done.

In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not. 

Let me know comments suggestions you may have.

Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev

Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski

Differential Revision: http://reviews.llvm.org/D16784

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259977 91177308-0d34-0410-b5e6-96231b3b80d8

[modules] Compress files embedded into a .pcm file, to reduce the disk usage of -fembed-all-files mode.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259976 91177308-0d34-0410-b5e6-96231b3b80d8

It is possible for enums to be created as part of their own
declcontext. We need to cache a placeholder to avoid the type being
created twice before hitting the cache.

<rdar://problem/24493203>

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259975 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259950 91177308-0d34-0410-b5e6-96231b3b80d8

Sometimes, char arrays are used as bit storage, with no difference made between
signed and unsigned char.  Thus, it is reasonable to use 0 to 255 instead of
-128 to 127 and not trigger this warning.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259947 91177308-0d34-0410-b5e6-96231b3b80d8

... and pull global-scope ones into std namespace with using-declaration.

Differential Revision: http://reviews.llvm.org/D16932

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259944 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259935 91177308-0d34-0410-b5e6-96231b3b80d8

rdar://24531556

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259932 91177308-0d34-0410-b5e6-96231b3b80d8

Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248] macros on SystemZ.

This fixes a miscompile of GCC C++11 standard library headers
due to use of those macros in an ABI-changing manner.

See e.g. /usr/include/c++/4.8.5/ext/concurrence.h:

  // Compile time constant that indicates prefered locking policy in
  // the current configuration.
  static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
     && defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
  _S_atomic;
#else
  _S_mutex;
#endif
#else
  _S_single;
#endif

A different choice of __default_lock_policy causes different
sizes of several of the C++11 data structures, which are then
incompatible when inlined in clang-compiled code with what the
(GCC-compiled) external library expects.

This in turn leads to various crashes when using std::thread
in code compiled with clang, as see e.g. via the ThreadPool
unit tests.  See PR 26473 for an example.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259931 91177308-0d34-0410-b5e6-96231b3b80d8

This change reverts r257462 for PS4 triple.

Differential Revision: http://reviews.llvm.org/D16788


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259916 91177308-0d34-0410-b5e6-96231b3b80d8

In the context where we break one tok::greatergreater into two
tok::greater in order to correctly update the cached tokens; update the
CachedTokens with two tok::greater only if ParseGreaterThanInTemplateList
clients asks to consume the last token. Otherwise we only need to add
one because the second is already added later on, as a not yet cached token.

Differential Revision: http://reviews.llvm.org/D16906

rdar://problem/24488367

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259910 91177308-0d34-0410-b5e6-96231b3b80d8

name lookup information have changed since deserialization. For a C++ modules
build, we do not need to re-emit the identifier into the serialized identifier
table if only the name lookup information has changed (and in all cases, we
don't need to re-emit the macro information if only the name lookup information
has changed).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259901 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Allow hasName() to look through inline namespaces.
This will fix the interaction between some clang-tidy checks and libc++.

libc++ defines names in an inline namespace named std::<version_#>.
When we try to match a name using hasName("std::xxx") it fails to match and the clang-tidy check does not work.

Reviewers: klimek

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D15506

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259898 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  f(a.operator() < A > ());

After:
  f(a.operator()<A>());

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259884 91177308-0d34-0410-b5e6-96231b3b80d8

If the class or method name case-insensitively contains the term "debug",
suppress warnings about string constants flowing to user-facing UI APIs.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259875 91177308-0d34-0410-b5e6-96231b3b80d8

Because the Decl is explicitly passed as nullptr further up the call chain, it
is possible to invoke isa on a nullptr, which will assert.  Guard against the
nullptr.

Take the opportunity to reuse the helper method rather than re-implementing this
logic.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259874 91177308-0d34-0410-b5e6-96231b3b80d8

call in one more place to reduce the size of identifier tables in non-leaf
modules. No behavior change.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259866 91177308-0d34-0410-b5e6-96231b3b80d8

When building a PCH with modules enabled this import would assert in the
ASTWriter and (if assertions were disabled) sometimes crash the compiler
that loaded the resulting PCH when trying to lookup the submodule ID.

rdar://problem/24137448

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259859 91177308-0d34-0410-b5e6-96231b3b80d8

template, keep looking for default arguments if we see a template parameter
pack. There may be default arguments preceding a pack with no default argument.

Patch by Jannis Harder!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259836 91177308-0d34-0410-b5e6-96231b3b80d8

If the typo happens after a successful deduction for an earlier
return statement, we should check if the deduced type is null
before using it.

The typo correction happens after we try to deduce the return
type and we ignore the deduction from the typo and continue
to typo correction.

rdar://24342247


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259820 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259819 91177308-0d34-0410-b5e6-96231b3b80d8

This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.

Review: http://reviews.llvm.org/D16730


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259811 91177308-0d34-0410-b5e6-96231b3b80d8

Differential Revision: http://reviews.llvm.org/D16626


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259780 91177308-0d34-0410-b5e6-96231b3b80d8

Codegen for array sections/array subscripts worked only for expressions with arrays as base. Patch fixes codegen for bases with pointer/reference types.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259776 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM can now lower TLS access as per the MS ABI on ARM.  This enables the
generation of TLS access for Windows on ARM.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259751 91177308-0d34-0410-b5e6-96231b3b80d8

PR23057: fix use-after-free due to local token buffer in ParseCXXAmbiguousParenExpression, by Dmitry Polukhin
Differential Revision: http://reviews.llvm.org/D16572
A    test/Parser/cxx-ambig-paren-expr-asan.cpp
M    lib/Parse/ParseExprCXX.cpp


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259750 91177308-0d34-0410-b5e6-96231b3b80d8

Per review feedback the name was wrong and it can be used outside
Objective-C.

Unfortunately, making the internal struct visible broke some ASTMatchers
tests that assumed that the first record decl would be from user code,
rather than a builtin type.  I'm worried that this will also affect
users' code.  So this patch adds a typedef to wrap the internal struct
and only makes the typedef visible to namelookup.  This is sufficient to
allow the ASTReader to merge the decls we need without making the struct
itself visible.

rdar://problem/24425801

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259734 91177308-0d34-0410-b5e6-96231b3b80d8

Original message:
Make CF constant string decl visible to name lookup to fix module errors

The return type of the __builtin___*StringMakeConstantString functions
is a pointer to a struct, so we need that struct to be visible to name
lookup so that we will correctly merge multiple declarations of that
type if they come from different modules.

Incidentally, to make this visible to name lookup we need to rename the
type to __NSConstantString, since the real NSConstantString is an
Objective-C interface type.  This shouldn't affect anyone outside the
compiler since users of the constant string builtins cast the result
immediately to CFStringRef.

Since this struct type is otherwise implicitly created by the AST
context and cannot access namelookup, we make this a predefined type
and initialize it in Sema.

Note: this issue of builtins that refer to types not visible to name
lookup technically also affects other builtins (e.g. objc_msgSendSuper),
but in all other cases the builtin is a library builtin and the issue
goes away if you include the library that defines the types it uses,
unlike for these constant string builtins.

rdar://problem/24425801


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259721 91177308-0d34-0410-b5e6-96231b3b80d8

Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.

http://reviews.llvm.org/D16823

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259716 91177308-0d34-0410-b5e6-96231b3b80d8