I made some small changes in smmintrin.h and emmintrin.h intrinsics.
 - changed some regular comments '//' into doxygen-style comments '///' where necessary
 - removed some trailing spaces in doxygen comments.

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.



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

Reviewers: Anastasia, cfe-commits

Reviewed By: Anastasia

Subscribers: bader, yaxunl

Differential Revision: https://reviews.llvm.org/D30937

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

Summary: I added a new rank to ImplicitConversionRank enum to resolve the function overload ambiguity with vector types. Rank of scalar types conversion is lower than vector splat. So, we can choose which function should we call. See test for more details.

Reviewers: Anastasia, cfe-commits

Reviewed By: Anastasia

Subscribers: bader, yaxunl

Differential Revision: https://reviews.llvm.org/D30816

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

Differential Revision: https://reviews.llvm.org/D31155

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

Differential Revision: https://reviews.llvm.org/D30861


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

This commit adds support for a new attribute that will be used to
distinguish between extensible and inextensible enums. There are three
main purposes of this attribute:

1. Give better control over when enum-related warnings are issued.
For example, in the code below, clang will not issue a -Wassign-enum
warning if the enum is marked "open":

enum __attribute__((enum_extensibility(closed))) EnumClosed {
  B0 = 1, B1 = 10
};

enum __attribute__((enum_extensibility(open))) EnumOpen {
  C0 = 1, C1 = 10
};

enum EnumClosed ec = 100; // warning issued
enum EnumOpen eo = 100; // no warning

2. Enable code-completion and debugging tools to offer better
suggestions.

3. Make it easier for swift's clang importer to determine which swift
type an enum should be mapped to.

For more details, see the discussion I started on cfe-dev:
http://lists.llvm.org/pipermail/cfe-dev/2017-February/052748.html

rdar://problem/12764379
rdar://problem/23145650

Differential Revision: https://reviews.llvm.org/D30766

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

Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.

Part of the fix for PR32334.

Differential Revision: https://reviews.llvm.org/D31162

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

In doing so, clean up the MD5 interface a little.  Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface.  Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.

Differential Revision: https://reviews.llvm.org/D31105

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

 - Fix a variable naming mismatch
 - Fix gcc extension pointer arithmetic on void to cast to char *.
 - Test that the header (and htmintrin.h) parse.

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

PR32346 suggests that UBSan's docs about the -fsanitize,
-fno-sanitize-recover, and -fsanitize-trap options are not explicit
enough. Try to improve the wording.

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

available by default on those cpus and configurations.

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

Summary: Proposal: Backward-edge CFI for return statements (RCFI)

Reviewers: pcc, eugenis, krasin

Reviewed By: eugenis

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D31112

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

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

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

This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338).  The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.

Original commit message follows:

----

Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands).  Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly.  Furthermore, the LockFileManager is not
robust in every environment.  Other -cc1 commands can stall until
timeout (after about eight minutes).

This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack.  The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module.  Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout.  Perhaps we should
reconsider blocking at all.

This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.

The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename.  Its ownership is shared by the
CompilerInstance and ModuleManager.

- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.

- When modules fail to validate, they're removed from the cache.

- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.

- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.

Original patch by Manman Ren; most testcases by Adrian Prantl!

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

... mostly having to do with code blocks which the syntax highlighter chokes on


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

Review: D30830

Patch by James Price!



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

Reviewers: djasper

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D30990

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

Differential Revision: https://reviews.llvm.org/D30862


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

The comment about there being three different forms that Ptr represents was stale. Also, the opaque value does not need to be exposed (these functions are unused).

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

Summary:
Adding missing intrinsics :
    _mm512_set_epi16,
    _mm512_set_epi8,
    _mm512_permutevar_epi32
    _mm512_mask_permutevar_epi32

Reviewers: zvi, guyblank, eladcohen, craig.topper

Reviewed By: craig.topper

Subscribers: craig.topper, cfe-commits

Differential Revision: https://reviews.llvm.org/D31034

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

This reverts commit r298165, as it broke the ARM builds.

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

Reviewers: rnk, mkuper

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D27051

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

Duncan's r298165 introduced the PCMCache mechanism, which guarantees
that locks aren't necessary anymore for correctness but only for
performance, by avoiding building it twice when possible.

Change the logic to avoid an error but actually build the module in case
the timeout happens. Instead of an error, still emit a remark for
debugging purposes.

rdar://problem/30297862

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

[index] For C++ constructors/destructors, add references to the parent type where its name appears in definitions and declarations

Patch by Nathan Hawes!
https://reviews.llvm.org/D30730

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

Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands).  Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly.  Furthermore, the LockFileManager is not
robust in every environment.  Other -cc1 commands can stall until
timeout (after about eight minutes).

This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack.  The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module.  Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout.  Perhaps we should
reconsider blocking at all.

This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.

The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename.  Its ownership is shared by the
CompilerInstance and ModuleManager.

  - The ModuleManager stores PCMs there that it loads from disk, never
    touching the disk if the cache is hot.

  - When modules fail to validate, they're removed from the cache.

  - When a CompilerInstance is spawned to build a new module, each
    already-loaded PCM is assumed to be valid, and is frozen to avoid
    the use-after-free.

  - Any newly-built module is written directly to the cache to avoid the
    round-trip to the filesystem, making lock files unnecessary for
    correctness.

Original patch by Manman Ren; most testcases by Adrian Prantl!

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

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

Summary:
3.4.6 [basic.lookup.udir] paragraph 1:
In a using-directive or namespace-alias-definition, during the lookup for a namespace-name or for a name in a nested-name-specifier, only namespace names are considered.

Reviewers: rsmith, aaron.ballman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D30848

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

clang-cl works best when the user runs vcvarsall to set up
an environment before running, but even this is not enough
on VC 2017 when cross compiling (e.g. using an x64 toolchain
to target x86, or vice versa).

The reason is that although clang-cl itself will have a
valid environment, it will shell out to other tools (such
as link.exe) which may not.  Generally we solve this through
adding the appropriate linker flags, but this is not enough
in VC 2017.

The cross-linker and the regular linker both link against
some common DLLs, but these DLLs live in the binary directory
of the native linker.  When setting up a cross-compilation
environment through vcvarsall, it will add *both* directories
to %PATH%, so that when cl shells out to any of the associated
tools, those tools will be able to find all of the dependencies
that it links against.  If you don't do this, link.exe will
fail to run because the loader won't be able to find all of
the required DLLs that it links against.

To solve this we teach the driver how to spawn a process with
an explicitly specified environment.  Then we modify the
PATH before shelling out to subtools and run with the modified
PATH.

Patch by Hamza Sood
Differential Revision: https://reviews.llvm.org/D30991

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

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

[AVX-512] Change the input type for some load intrinsics to take void type like the spec (and the test cases say).

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

[AVX-512] Fix test cases that were using the builtins directly without typecasts instead of the intrinsic header.

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

[AVX-512] Add missing typecasts and parentheses to _mm512_mask_i64gather_ps. My macro cleanup script I used on the others last year must have missed it.

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

[Serialization] Follow-up to r297972, deserialize name/loc in separate statements to make sure they deserialize in defined order.

This should fix the windows bots.

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

unused anywhere in llvm.

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

Reapply r289181 but rename the include guard to avoid
conflict with the one from Darwin.

Allow darwin to provide additional definitions and implementation
specifc values for tgmath.h on Apple platforms.

rdar://problem/19019845

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

Expand a bit on private modules with some guidance on how to write
them in the context of frameworks.

rdar://problem/24758771

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

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

Patch by: Mateusz Mikula

Reviewers: rnk

Reviewed By: rnk

Subscribers: asl, mgorny, cfe-commits

Tags: #clang-c

Differential Revision: https://reviews.llvm.org/D29772

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

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