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

The enum is part of ArrayType, so there is no functional change, but comparing
to ArrayType::Static for non-VLAs makes more sense.

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

C99 array parameters can have index-type CVR qualifiers, and the TypePrinter
should print them when present (and we were not for constant-sized arrays).
Otherwise, we'd drop the restrict in:

  int foo(int a[restrict static 3]) { ... }

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

In C99, an array parameter declarator might have the form:
  direct-declarator '[' 'static' type-qual-list[opt] assign-expr ']'

where the static keyword indicates that the caller will always provide a
pointer to the beginning of an array with at least the number of elements
specified by the assignment expression. For constant sizes, we can use the
new dereferenceable attribute to pass this information to the optimizer. For
VLAs, we don't know the size, but (for addrspace(0)) do know that the pointer
must be nonnull (and so we can use the nonnull attribute).

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

ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.


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

FIXME: Could this be made generic?

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

It's also possible to just write "= nullptr", but there's some question
of whether that's as readable, so I leave it up to authors to pick which
they prefer for now. If we want to discuss standardizing on one or the
other, we can do that at some point in the future.

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

Assigns indices to try blocks. These indices will used in constructing 
tables that the mscrt function __except_handler3 reads during SEH.
Testing will occur once we actually emit the tables, in a subsequent 
patch.



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

Thoroughly check for a pointer dereference which yields a glvalue.  Look
through casts, comma operators, conditional operators, paren
expressions, etc.

This was originally D4416.

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

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

CGBuilder doesn't name instructions with Name. We should use Inst::setName() to name an instruction explicitly here.

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

<rdar://problem/17476689>


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

In C99, an array parameter declarator might have the form: direct-declarator
'[' 'static' type-qual-list[opt] assign-expr ']'

and when the size of the array is a constant, don't omit the static keyword
when printing the type. Also, in the VLA case, put a space after the static
keyword (some assignment expression must follow it).

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

is unused (this is match behavior when property-dot syntax is used to
use same getter). rdar://17514245
Patch by Anders Carlsson with minor refactoring by me.


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

thorough tests.

Original commit message:

[modules] Fix macro hiding bug exposed if:

 * A submodule of module A is imported into module B
 * Another submodule of module A that is not imported into B exports a macro
 * Some submodule of module B also exports a definition of the macro, and
   happens to be the first submodule of B that imports module A.

In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.

This happens with the 'assert' macro in an LLVM self-host. =(


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

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

This reverts commit r213401, r213402, r213403, and r213404.

I accidently committed these changes instead of updating the
differential.

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

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

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

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

Summary:
Thoroughly check for a pointer dereference which yields a glvalue.  Look
through casts, comma operators, conditional operators, paren
expressions, etc.

Reviewers: rsmith

Subscribers: cfe-commits

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

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

Clang uses a diagnostic handler to grab diagnostic messages so it can print them
with the line of source code they refer to. This patch extends this to handle
optimization failures that were added to llvm to produce a warning when
loop vectorization is explicitly specified (using a pragma clang loop directive)
but fails.

Update renames warning flag name to avoid indicating the flag's severity and
adds a test.

Reviewed by Alp Toker



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

This is breaking the system modules on Darwin, because something that
was defined and re-exported no longer is.  Might be this patch, or might
just be a really poor interaction with an existing visibility bug.

This reverts commit r213348.

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

Otherwise -fsanitize=vptr causes the program to crash when it downcasts
a null pointer.

Reviewed in http://reviews.llvm.org/D4412.
Patch by Byoungyoung Lee!


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

Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
llvm.asan.globals metadata, effectively "blacklisting" them. This can
dramatically decrease the data section in binaries built with UBSan+ASan,
as UBSan tends to create a lot of handlers, and ASan instrumentation
increases the global size to at least 64 bytes.

Test Plan: clang regression test suite

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, byoungyoung, kcc

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

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

(i486-linux-gnu previously). Adding this triple to the list of search.
Also impacts clang 3.4.2

Reported on the Debian bug tracking system here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754963
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755183




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

Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.

Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.

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

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

This reverts commit dbf785a6, while I qm
investigating a buildbot failure.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213380 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@213379 91177308-0d34-0410-b5e6-96231b3b80d8

to the user if they try to pass those optimizations. The revision for this patch
is here: http://reviews.llvm.org/D4474. This patch will fix many errors in the
rebuild of Debian with clang. Here is a link to the page for unknown arguments:
http://clang.debian.net/status.php?version=3.4.2&key=UNKNOWN_ARG


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

Add an additional test to ensure that someone doesn't accidentally
change the definitions such that they can take a non-constant value.


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

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