AttributeReference.rst is automatically generated by a server-side process currently. To cut down on accidental commits to this file that are not properly reflected in AttrDocs.td (such as r215806 - r215808), this file now contains nothing but a comment explaining the current state of affairs.

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

Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0).


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

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

Moving r215806, r215807, and r215808 into AttrDocs.td. These changes were originally applied to the RST file that is automatically generated by the server, and so the changes were never properly reflected online once the server overwrote AttributeReference.rst.

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

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

Clarify pointer ownership semantics by hoisting the std::unique_ptr creation to the caller instead of hiding it in emitReport. NFC.

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

FIXME: Should "Level" be unsigned?

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

not all control paths return a value.



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

they can write to the current working directory.

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

Tweak clang/test/Modules/modules-with-same-name.m to run with GnuWin32's find.exe on newer version of Windows.

It seems "*.pcm" would be expanded with current directory by NTOS 6.x's msvcrt. GnuWin32 utils are affected.
To avoid the issue, put an expression that msvcrt's glob won't match, like "*.pc[m]".

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

Member pointers in the MS ABI are made complicated due to the following:
- Virtual methods in the most derived class (MDC) might live in a
  vftable in a virtual base.
- There are four different representations of member pointer: single
  inheritance, multiple inheritance, virtual inheritance and the "most
  general" representation.
- Bases might have a *more* general representation than classes which
  derived from them, a most surprising result.

We believed that we could treat all member pointers as-if they were a
degenerate case of the multiple inheritance model.  This fell apart once
we realized that implementing standard member pointers using this ABI
requires referencing members with a non-zero vbindex.

On a bright note, all but the virtual inheritance model operate rather
similarly.  The virtual inheritance member pointer representation
awkwardly requires a virtual base adjustment in order to refer to
entities in the MDC.

However, the first virtual base might be quite far from the start of the
virtual base.  This means that we must add a negative non-virtual
displacement.

However, things get even more complicated.  The most general
representation interprets vbindex zero differently from the virtual
inheritance model: it doesn't reference the vbtable at all.

It turns out that this complexity can increase for quite some time:
consider a derived to base conversion from the most general model to the
multiple inheritance model...

To manage this complexity we introduce a concept of "normalized" member
pointer which allows us to treat all three models as the most general
model.  Then we try to figure out how to map this generalized member
pointer onto the destination member pointer model.  I've done my best to
furnish the code with comments explaining why each adjustment is
performed.

This fixes PR23878.

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

The MS ABI has very complicated member pointers.  Don't attempt to
synthesize the final member pointer ab ovo usque ad mala in one go.

Instead, start with a member pointer which points to the declaration in
question as-if it's decl context was the target class.  Then, utilize
our conversion logical to convert it to the target type.

This allows us to simplify how we think about member pointers because we
don't need to consider non-zero nv adjustments before we even generate
the member pointer.  Furthermore, it gives our adjustment logic more
exposure by utilizing it in a common path.

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

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

Currently if the variable is captured in captured region, capture record for this region stores reference to this variable for future use. But we don't need to provide the reference to the original variable if it was explicitly marked as private in the 'private' clause of the OpenMP construct, this variable is replaced by private copy.
Differential Revision: http://reviews.llvm.org/D9550


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

(Caused by r240370)

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

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

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

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

file in the loaded module maps and one of them is from the current module,
that's the right match.


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

Update for LLVM API change to return by InputArgList directly (rather than by pointer) from ParseArgs

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

As specified in the SysV AVX512 ABI drafts. It follows the same scheme
as AVX2: 

    Arguments of type __m512 are split into eight eightbyte chunks.
    The least significant one belongs to class SSE and all the others
    to class SSEUP.

This also means we change the OpenMP SIMD default alignment on AVX512.

Based on r240337.
Differential Revision: http://reviews.llvm.org/D9894


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

Follow-up to r237989: expressing the AVX level as an enum makes it
simple to extend it with AVX512.


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

[modules] Add a flag to disable the feature that permits conflicting redefinitions of internal-linkage symbols that are not visible.

Such conflicts are an accident waiting to happen, and this feature conflicts
with the desire to include existing headers into multiple modules and merge the
results. (In an ideal world, it should not be possible to export internal
linkage symbols from a module, but sadly the glibc and libstdc++ headers
provide 'static inline' functions in a few cases.)


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

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

The asan/not_asan and ubsan/not_ubsan features weren't being set
correctly when LLVM_USE_SANITIZER is set to 'Address;Undefined'. Fix
this by doing substring instead of exact matching. Also simplify the
msan check for consistency.

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

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

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

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

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

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



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

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

The same pattern was repeated a few times.  Create a trivial helper method to
map the Type Specifier to an ID for the diagnostic.  Flip the selection order on
one of the diagnostic messages to get the same ordering across all of the
messages.  This makes the emission of the diagnostic slightly more legible by
changing the cascading ternary into a switch in a function.  NFC.

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

Move /Qvec flags from the "// Non-aliases:" section up to the "// Aliases:"
section since the flags are just aliases.  For the same reason, move the
/vm flags the other way.  Also reflow a few lines to 80 columns.

No behavior change.


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

This is a better approach to fixing the undefined behaviour I tried to
fix in r240228. This data doesn't necessarily have suitable alignment
for uint64_t, so use unaligned_uint64_t instead.

This fixes 225 test failures when clang is built with ubsan.

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

We can do this better by changing the type to unaligned_uint64_t and
paying the cost on use instead of up front.

This reverts r240228

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

Convert a hand rolled for loop into an explicit for loop.  NFC.

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

Testcase provided, in the PR, by Christian Shelton and
reduced by David Majnemer.

PR:		23584
Differential Revision:	http://reviews.llvm.org/D10508
Reviewed by:	rnk


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

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

We interpret Blob as an array of uint64_t here, but there's no reason
to think that it has suitable alignment. Instead, read the data in in
an alignment-safe way and store it in a std::vector.

This fixes 225 test failures when clang is built with ubsan.

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

A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.

The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.

rdar://problem/20091852

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

We already test for PrioritizedCXXGlobalInits being non-empty
and process it so it makes sense to clear it only in that if.



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