When building with modules enabled, we were defining max_align_t as a typedef
for a different anonymous struct type each time it was included, resulting in
an error if <stddef.h> is not covered by a module map and is included more than
once in the same modules-enabled compilation of C11 or C++11 code.


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

for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
 methods and Bob Wilson has fixed a TableGen of FastISel so
 no warnings are expected from build of llvm after this patch.
 I have already verified this). 


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

This reverts commit r218913 while I investigate some bots.

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

Update debug info testcases for an LLVM metadata schema change to fold
metadata constant operands into a single `MDString`.

Part of PR17891.

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

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

This adds support for the align_value attribute. This attribute is supported by
Intel's compiler (versions 14.0+), and several of my HPC users have requested
support in Clang. It specifies an alignment assumption on the values to which a
pointer points, and is used by numerical libraries to encourage efficient
generation of vector code.

Of course, we already have an aligned attribute that can specify enhanced
alignment for a type, so why is this additional attribute important? The
problem is that if you want to specify that an input array of T is, say,
64-byte aligned, you could try this:

  typedef double aligned_double attribute((aligned(64)));
  void foo(aligned_double *P) {
    double x = P[0]; // This is fine.
    double y = P[1]; // What alignment did those doubles have again?
  }

the access here to P[1] causes problems. P was specified as a pointer to type
aligned_double, and any object of type aligned_double must be 64-byte aligned.
But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes
undefined behavior. Getting round this problem requires a lot of awkward
casting and hand-unrolling of loops, all of which is bad.

With the align_value attribute, we can accomplish what we'd like in a well
defined way:

  typedef double *aligned_double_ptr attribute((align_value(64)));
  void foo(aligned_double_ptr P) {
    double x = P[0]; // This is fine.
    double y = P[1]; // This is fine too.
  }

This attribute does not create a new type (and so it not part of the type
system), and so will only "propagate" through templates, auto, etc. by
optimizer deduction after inlining. This seems consistent with Intel's
implementation (thanks to Alexey for confirming the various Intel-compiler
behaviors).

As a final note, I would have chosen to call this aligned_value, not
align_value, for better naming consistency with the aligned attribute, but I
think it would be more useful to users to adopt Intel's name.

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

Prior to GCC 4.4, __sync_fetch_and_nand was implemented as:

  { tmp = *ptr; *ptr = ~tmp & value; return tmp; }

but this was changed in GCC 4.4 to be:

  { tmp = *ptr; *ptr = ~(tmp & value); return tmp; }

in response to this change, support for sync_fetch_and_nand (and
sync_nand_and_fetch) was removed in r99522 in order to avoid miscompiling code
depending on the old semantics. However, at this point:

  1. Many years have passed, and the amount of code relying on the old
     semantics is likely smaller.

  2. Through the work of many contributors, all LLVM backends have been updated
     such that "atomicrmw nand" provides the newer GCC 4.4+ semantics (this process
     was complete July of 2014 (added to the release notes in r212635).

  3. The lack of this intrinsic is now a needless impediment to porting codes
     from GCC to Clang (I've now seen several examples of this).

It is true, however, that we still set GNUC_MINOR to 2 (corresponding to GCC
4.2). To compensate for this, and to address the original concern regarding
code relying on the old semantics, I've added a warning that specifically
details the fact that the semantics have changed and that we provide the newer
semantics.

Fixes PR8842.

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

separators in my previous patch. 


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

Summary:
Currently, with struct my_struct { int x; method_ptr y; };
a call to foo(my_struct s) may end up dropping the last 4 bytes
of the method pointer for x86_64 NaCl and x32.

When checking Has64BitPointers, also check if the method pointer
straddles an eightbyte boundary and classify Hi as well as Lo if needed.

Test Plan: test/CodeGenCXX/x86_64-arguments-nacl-x32.cpp

Reviewers: dschuff, pavel.v.chupin

Subscribers: jfb

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

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

Reapplying now that r218887 is in.

This reverts commit r218882, reapplying r218880.

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

number separator in "availability" attribute.
rdar://18490958


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

r218879 has been reverted for now, this needs to go to match.

This reverts commit r218880.

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

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

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

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

Summary: Commit r218863 broke this test case. This patch fixes it
by updating the expected output line. Should've been updated with
the original patch but for some reason it didn't fail during my
local make check.

Change-Id: I89ed28b37f67c34d1a5d28a3e47ae33d9a82a98f

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

Summary: This patch implements warnings/downgradable errors for
invalid -mfpu, -mfloat-abi option combinations (e.g. -mfpu=none
-mfloat-abi=hard).

Change-Id: I94fa664e1bc0b5855ad835abd7a50a3e0395632d

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

I couldn't get something /really/ obvious, and I imagine Richard Smith
might be able to provide some text explaining the sequence of steps
that's demonstrated by these files - but at least it's a bit simpler
now.

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

Suggested by Richard Smith.
rdar://18508589.


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

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

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

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

before the semicolon wahen modernizing to use 
NS_ENUM/NS_OPTIONS macros. rdar://18498539


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

Update for corresponding LLVM API change for
`DIBuilder::createExpression()`.

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

Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar://problem/17994491

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

"Update CGDebugInfo to the updated API in LLVM."

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

to recover from parse error parsing the default
argument. Patch prevents crash after spewing 100s 
of errors caused by someone who forgot to compile in c++11
mode. So no test. rdar://18508589 


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

Do not use delegated constructors.
It is not supported on all platforms yet.
Fixes build broken by r218769.

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

Complex address expressions are no longer part of DIVariable, but
rather an extra argument to the debug intrinsics.

http://reviews.llvm.org/D4919
rdar://problem/17994491

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

These were uncoveredby my yet undelivered patch.


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

Summary:
This change introduces DynMatcherInterface and changes the internal
representation of DynTypedMatcher and Matcher<T> to use a generic
interface instead.
It removes unnecessary indirections and virtual function calls when
converting matchers by implicit and dynamic casts.
DynTypedMatcher now remembers the stricter type in the chain of casts
and checks it before calling into DynMatcherInterface.
This change improves our clang-tidy related benchmark by ~14%.
Also, it opens the door for more optimizations of this kind that are
coming in future changes.

As a side effect of removing these template instantiations, it also
speeds up compilation of Dynamic/Registry.cpp by ~17% and reduces the
number of
symbols generated by ~30%.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

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

The Cortex-M7 has 3 options for its FPU: none, FPv5-SP-D16 and
FPv5-DP-D16. FPv5 has the same instructions as FP-ARMv8, so it can be
modeled using the same target feature, and all double-precision
operations are already disabled by the fp-only-sp target features.



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

This patch implements collapsing of the loops (in particular, in
presense of clause 'collapse'). It calculates number of iterations N
and expressions nesessary to calculate the nested loops counters
values based on new iteration variable (that goes from 0 to N-1)
in Sema. It also adds Codegen for 'omp simd', which uses
(and tests) this feature.

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



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

Get the record handling code from SelfReferenceChecker into
UninitializedFieldVisitor as well as copying the testcases.


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

When generating coverage regions, we were doing a linear search
through the existing regions in order to try to merge related ones.
Most of the time this would find what it was looking for in a small
number of steps and it wasn't a big deal, but in cases with many
regions and few mergeable ones this leads to an absurd compile time
regression.

This changes the coverage mapping logic to do a single sort and then
merge as we go, which is a bit simpler and about 100 times faster.
I've also added FIXMEs on a couple of behaviours that seem a little
suspect, while keeping them behaving as they were - I'll look into
these soon.

The test changes here are mostly tedious reorganization, because the
ordering of regions we output has become slightly (but not completely)
more consistent from the almost completely arbitrary ordering we got
before.

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

This struct has some members that are accessed directly and others
that need accessors, but it's all just public. This is confusing, so
I've changed it to a class and made more members private.

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

same coverage as the global checker.


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

being on by default. -fno-cxx-modules can still be used to enable C modules but
not C++ modules, but C++ modules is not significantly less stable than C
modules any more.

Also remove some of the scare words from the modules documentation. We're
certainly not going to remove modules support (though we might change the
interface), and it works well enough to bootstrap and build lots of
non-trivial code.

Note that this does not represent a commitment to the current interface nor
implementation, and we still intend to follow whatever direction the C and C++
committees take regarding modules support.


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

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

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

In code-completion, don't assume there is a MacroInfo for everything,
since we aren't serializing the def corresponding to a later #undef in
the same module.  Also setup the HadMacro bit correctly for undefs to
avoid an assertion failure.

rdar://18416901

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