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

Now that we support WoA, this test fails on ARM build bots as __va_start has a
different signature on different architectures.

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

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

Summary:
If during constructing a standard conversion sequence, we resolve an
overload, we need to adjust the from type in the SCS according to the
resolved operator.

I found this bug when debugging PR20218.  This doesn't seem to be
observable, so there is no good way of testing it.

Reviewers: rsmith

Subscribers: cfe-commits

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

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

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

Improve the checkUInt32Argument() helper function so that it diagnoses integer constants larger than 32-bits.

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

Provide extra information in the "integer constant is too large" diagnostic. This will be used to improve other diagnostics.

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

Adding a heading to the loop hint attributes so that attribute documentation can be generated again.

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

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

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

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

If it will not, I'm reverting the both commits.


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

The set is small, that what I have right now.
Everybody is welcome to add more.


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

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

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

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

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

a template argument.


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

Windows ARM indicates __va_start as a variadic function.  However, the function
itself is treated as having 4 formal arguments:
  - (out) pointer to the va_list
  - (in) address of the last named argument
  - (in) slot size for the type of the last argument
  - address of the last named argument

The last argument does not seem to have any bearing on codegen, and thus is not
explicitly type checked at this point.

Unlike the previous handling for __va_start, it does not currently validate if
the parameter is the last named parameter (it seems that MSVC currently accepts
this).

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

If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.

This patch fixes PR20055.

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


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

Summary:
This pragma is very rare.  We could *hypothetically* lower some uses of
it down to @llvm.global_ctors, but given that GlobalOpt isn't able to
optimize prioritized global ctors today, there's really no point.

If we wanted to do this in the future, I would check if the section used
in the pragma started with ".CRT$XC" and had up to two characters after
it.  Those two characters could form the 16-bit initialization priority
that we support in @llvm.global_ctors.  We would have to teach LLVM to
lower prioritized global ctors on COFF as well.

This should let us compile some silly uses of this pragma in WebKit /
Blink.

Reviewers: rsmith, majnemer

Subscribers: cfe-commits

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

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

Both /showIncludes and /E write to stdout. Allowing both results
in interleaved output and an error when double-closing the file
descriptor, intended to catch issues like this.

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

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

Previously it was hard-coded to 1.0, which meant the installer would
not install the plugin over previous versions.

This commit makes us use LLVM's major.minor.patch version from cmake,
or whatever CLANG_FORMAT_VS_VERSION is set to when configuring the build.

It's pretty dirty to update a configuration file in the source directory
from the cmake build like this. However, the plugin build is already
dirty in this regard since it builds in the source dir when visual studio,
and then copies out the resulting vsix.

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

This commit did break the sanitizer-x86 bot. Revert it while
investigating.

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

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

This will give more information to the optimizers so that they can reuse stack slots.

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

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

This fixes a couple of asserts when analyzing comparisons involving
C11 atomics that were uncovered by r205608 when we extended the
applicability of -Wtautological-constant-out-of-range-compare.

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

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

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

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

with overloads for designators_range and designators_const_range.


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

This field is never inspected in the object state initialized by this
constructor; however, initializing it seems reasonable, since it has
a meaningful value.


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

introduced by finalization. This is still not entirely correct; more fixes to
follow.


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

[OPENMP] Added several test cases for clauses 'ordered' and 'nowait': if there are more than one 'nowait' or 'ordered' clause an error message is expected.


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

In addition to enabling ELFv2 homogeneous aggregate handling,
LLVM support to pass array types directly also enables a performance
enhancement.  We can now pass (non-homogeneous) aggregates that fit
fully in registers as direct integer arrays, using an element type
to encode the alignment requirement (that would otherwise go to the
"byval align" field).

This is preferable since "byval" forces the back-end to write the
aggregate out to the stack, even if it could be passed fully in
registers.  This is particularly annoying on ELFv2, if there is
no parameter save area available, since we then need to allocate
space on the callee's stack just to hold those aggregates.

Note that to implement this optimization, this patch does not attempt
to fully anticipate register allocation rules as (defined in the
ABI and) implemented in the back-end.  Instead, the patch is simply
passing *any* aggregate passed by value using the array mechanism
if its size is up to 64 bytes.   This means that some of those will
end up being passed in stack slots anyway, but the generated code
shouldn't be any worse either.  (*Large* aggregates remain passed
using "byval" to enable optimized copying via memcpy etc.)



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

This patch implements clang support for the PowerPC ELFv2 ABI.
Together with a series of companion patches in LLVM, this makes
clang/LLVM fully usable on powerpc64le-linux.

Most of the ELFv2 ABI changes are fully implemented on the LLVM side.
On the clang side, we only need to implement some changes in how
aggregate types are passed by value.   Specifically, we need to:
- pass (and return) "homogeneous" floating-point or vector aggregates in
  FPRs and VRs (this is similar to the ARM homogeneous aggregate ABI)
- return aggregates of up to 16 bytes in one or two GPRs

The second piece is trivial to implement in any case.  To implement
the first piece, this patch makes use of infrastructure recently
enabled in the LLVM PowerPC back-end to support passing array types
directly, where the array element type encodes properties needed to
handle homogeneous aggregates correctly.

Specifically, the array element type encodes:
- whether the parameter should be passed in FPRs, VRs, or just
  GPRs/stack slots  (for float / vector / integer element types,
  respectively)
- what the alignment requirements of the parameter are when passed in
  GPRs/stack slots  (8 for float / 16 for vector / the element type
  size for integer element types) -- this corresponds to the
  "byval align" field

With this support in place, the clang part simply needs to *detect*
whether an aggregate type implements a float / vector homogeneous
aggregate as defined by the ELFv2 ABI, and if so, pass/return it
as array type using the appropriate float / vector element type.



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

... just to find out that it didn't build.

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

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