[clang-offload-bundler] Fix some Clang-tidy modernize-use-override and Include What You Use warnings; other minor fixes.

Differential revision: https://reviews.llvm.org/D24165



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

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

Summary: There was no definition for __nop function - added inline
assembly.

Patch by Albert Gutowski!

Reviewers: rnk, thakis

Subscribers: cfe-commits

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

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

Parse pragma intrinsic, display warning if the function isn't a builtin
function in clang and suggest including intrin.h.

Patch by Albert Gutowski!

Reviewers: aaron.ballman, rnk

Subscribers: aaron.ballman, cfe-commits

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

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

If the virtual method comes from a secondary vtable, then the type of
the 'this' parameter should be i8*, and not a pointer to the complete
class. In the MS ABI, the 'this' parameter on entry points to the vptr
containing the virtual method that was called, so we use i8* instead of
the normal type. We had a mismatch where the CGFunctionInfo of the call
didn't match the CGFunctionInfo of the declaration, and this resulted in
some assertions, but now both sides agree the type of 'this' is i8*.

Fixes one issue raised in PR30293

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

Reviewed by bruening
Differential: D23800


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

By default return type of call expressions calling built-in
functions is set to bool.

Fixes https://llvm.org/bugs/show_bug.cgi?id=30219.

Reviewers: Anastasia

Subscribers: dmitry, cfe-commits, yaxunl

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



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

OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.

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

^M and extra space

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

copy-initialization. We previously got this wrong in a couple of ways:
 - we only looked for copy / move constructors and constructor templates for
   this copy, and thus would fail to copy in cases where doing so should use
   some other constructor (but see core issue 670),
 - we mishandled the special case for disabling user-defined conversions that
   blocks infinite recursion through repeated application of a copy constructor
   (applying it in slightly too many cases) -- though as far as I can tell,
   this does not ever actually affect the result of overload resolution, and
 - we misapplied the special-case rules for constructors taking a parameter
   whose type is a (reference to) the same class type by incorrectly assuming
   that only happens for copy/move constructors (it also happens for
   constructors instantiated from templates and those inherited from base
   classes).

These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.


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

This commit improves compatibility with the perl version of scan-build.

The perl version of scan-build produces output report directories with
increasing lexicographic ordering. This ordering is relied on by the CmpRuns.py
tool in utils/analyzer when comparing results for build commands with multiple
steps. That tool tries to line up the output directory for each step between
different runs of the analyzer based on the increasing directory name.

The python version of scan-build uses file.mkdtemp() with a time stamp
prefix to create report directories. The timestamp has a 1-second precision.
This means that when analysis of a single build step takes less than a second
the ordering property that CmpRuns.py expects will sometimes not hold,
depending on the timing and the random suffix generated by mkdtemp(). Ultimately
this causes CmpRuns to incorrectly correlate results from build steps and report
spurious differences between runs.

This commit increases the precision of the timestamp used in scan-build-py to
the microsecond level. This approach still has the same underlying issue -- but
in practice analysis of any build step is unlikely to take less than a
millisecond.

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

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

Summary:
Before:
    x!as string
After:
    x! as string

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

Summary:
When code contains a comment between `return` and the value:

    return /* lengthy comment here */ (
        lengthyValueComesHere);

Do not wrap before the comment, as that'd break the code through JS' automatic
semicolon insertion.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

When calling getMostRecentDecl, we can pull in more definitions from
a module. We call getPrimaryContext afterwards to make sure that
we buildLookup on a primary context.

rdar://27926200


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

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

[clang-cl] Check that we are in clang cl mode before enabling support for the CL environment variable.

Checking for the type of the command line tokenizer should not be the criteria to enable support for the CL environment variable, this change checks that we are in clang-cl mode instead.

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

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

Use llvm::DINode::DIFlags type (strongly typed enum) for debug flags instead of unsigned int to avoid problems on platforms with sizeof(int) < 4: we already have flags with values > (1 << 16).

Patch by: Victor Leschuk <vleschuk@gmail.com>

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



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

Summary:
Remove access qualifiers on images in arg info metadata:
 * kernel_arg_type
 * kernel_arg_base_type

Image access qualifiers are inseparable from type in clang implementation,
but OpenCL spec provides a special query to get access qualifier
via clGetKernelArgInfo with CL_KERNEL_ARG_ACCESS_QUALIFIER.

Besides that OpenCL conformance test_api get_kernel_arg_info expects
image types without access qualifier.

Patch by Evgeniy Tyurin.

Reviewers: bader, yaxunl, Anastasia

Subscribers: cfe-commits

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



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

I'm in the progress of adding ARMv6 support to CloudABI. On the compiler
side, everything seems to work properly with this tiny change applied.



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

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

r280613 introduced failures for all builds that don't target x86 by default. Add an explicit target to avoid a missing feature diagnostic.

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

[AVX-512] Remove 128-bit and 256-bit masked floating point add/sub/mul/div builtins and replace with native operations.

We can't do the 512-bit ones because they take a rounding mode argument that we can't represent.

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

macros.


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

This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.

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



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

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

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

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

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

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

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

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

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

Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:

  [uuid("....")] class IBufferByteAccess {};

To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it.  Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.

Final part of https://reviews.llvm.org/D23895


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

There was already a function that moved attributes off the declspec into
an attribute list for attributes applying to the type, teach that function to
also move Microsoft attributes around and rename it to match its new broader
role.

Nothing uses Microsoft attributes yet, so no behavior change.

Part of https://reviews.llvm.org/D23895


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

This is for attributes in []-delimited lists preceding a class, like e.g.
`[uuid("...")] class Foo {};`  Not used by anything yet, so no behavior change.
Part of https://reviews.llvm.org/D23895


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

into ParseDeclOrFunctionDefInternal() (which is called by
MaybeParseMicrosoftAttributes()), so that the attributes can be stored in
the DeclSpec.  No behavior change yet, part of https://reviews.llvm.org/D23895


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

The comment starting with "ParseDeclarationOrFunctionDefinition -" is above
a function called ParseDeclOrFunctionDefInternal.  Fix the comment by not
mentioning a function name, like the style guide requests nowadays.  No behavior
change.


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

We have invariants we like to guarantee for the
`ImplicitConversionKind`s in a `StandardConversionSequence`. These
weren't being upheld in code that r280553 touched, so Richard suggested
that we should fix that. See D24113.

I'm not entirely sure how to go about testing this, so no test case is
included. Suggestions welcome.


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

Clang tests for verifying the following syntaxes:
1. 0xNN and NNh are accepted as valid hexadecimal numbers, but 0xNNh is not.     
   0xNN and NNh may come with optional U or L suffix.                            
2. NNb is accepted as a valid binary (base-2) number, but 0bNN is not.           
   NNb may come with optional U or L suffix.                                     
                                                                                 
Differential Revision: https://reviews.llvm.org/D22112



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

This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):

```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));

void callFoo() {
  unsigned char bar[128];
  foo(bar); // selects the char* overload.
}
```

These conversions are ranked below all others, so:

  A. Any other viable conversion will win out
  B. If we had another incompatible pointer conversion in the example
     above (e.g. `void foo(int *)`), we would complain about
     an ambiguity.

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


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

Summary:
This attribute specifies expectations about the initialization of static and
thread local variables. Specifically that the variable has a
[constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
according to the rules of [basic.start.static]. Failure to meet this expectation
will result in an error.

Static objects with constant initializers avoid hard-to-find bugs caused by
the indeterminate order of dynamic initialization. They can also be safely
used by other static constructors across translation units.

This attribute acts as a compile time assertion that the requirements
for constant initialization have been met. Since these requirements change
between dialects and have subtle pitfalls it's important to fail fast instead
of silently falling back on dynamic initialization.

```c++
  // -std=c++14
  #define SAFE_STATIC __attribute__((require_constant_initialization)) static
  struct T {
    constexpr T(int) {}
    ~T();
  };
  SAFE_STATIC T x = {42}; // OK.
  SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
  // copy initialization is not a constant expression on a non-literal type.
```
This attribute can only be applied to objects with static or thread-local storage
duration.

Reviewers: majnemer, rsmith, aaron.ballman

Subscribers: jroelofs, cfe-commits

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

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