InstrProf: Update for the LLVM API change in r218879

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218880 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "InstrProf: Update for the LLVM API change in r218879"

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
Patch to accept '_' in addition to '.' as version
number separator in "availability" attribute.
rdar://18490958


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218884 91177308-0d34-0410-b5e6-96231b3b80d8
Reapply "InstrProf: Update for the LLVM API change in r218879"

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
[x32/NaCl] Check if method pointers straddle an eightbyte to classify Hi

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
Diagnose mixed use of '_' and '.' as version
separators in my previous patch. 


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

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
Initial support for the align_value attribute

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
Reflowing some comments, NFC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218912 91177308-0d34-0410-b5e6-96231b3b80d8
DI: LLVM schema change: fold constants into string

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
Revert "DI: LLVM schema change: fold constants into string"

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
Patch to warn if 'override' is missing
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
Fix interaction of max_align_t and modules.

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
Driver: Use pointee_iterator rather than iterating over unique_ptrs

There's probably never a good reason to iterate over unique_ptrs. This
lets us use range-for and say Job.foo instead of (*it)->foo in a few
places.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218938 91177308-0d34-0410-b5e6-96231b3b80d8
Driver: Update clang-interpreter example for r218938

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218942 91177308-0d34-0410-b5e6-96231b3b80d8
Add an implementation of C11's stdatomic.h

Adds a Clang-specific implementation of C11's stdatomic.h header. On systems,
such as FreeBSD, where a stdatomic.h header is already provided, we defer to
that header instead (using our __has_include_next technology). Otherwise, we
provide an implementation in terms of our __c11_atomic_* intrinsics (that were
created for this purpose).

C11 7.1.4p1 requires function declarations for atomic_thread_fence,
atomic_signal_fence, atomic_flag_test_and_set,
atomic_flag_test_and_set_explicit, and atomic_flag_clear, and requires that
they have external linkage. Accordingly, we provide these declarations, but if
a user elides the shadowing macros and uses them, then they must have a libc
(or similar) that actually provides definitions.

atomic_flag is implemented using _Bool as the underlying type. This is
consistent with the implementation provided by FreeBSD and also GCC 4.9 (at
least when __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1).

Patch by Richard Smith (rebased and slightly edited by me -- Richard said I
should drive at this point).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218957 91177308-0d34-0410-b5e6-96231b3b80d8
Revert useless part of r217349

Adding handling of __builtin_assume_aligned to IntExprEvaluator does not make
sense because __builtin_assume_aligned returns a pointer (not an integer).
Thanks to Richard for figuring out why this was not doing anything.

I'll add this back in a better place (PointerExprEvaluator perhaps).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218958 91177308-0d34-0410-b5e6-96231b3b80d8
Make test/Sema/atomic-ops.c free-standing

This test includes stdint.h, which might include system headers (and that might
not work, depending on the system configuration). Attempting to fix
llvm-clang-lld-x86_64-debian-fast.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218959 91177308-0d34-0410-b5e6-96231b3b80d8
Make test/CodeGen/atomic-ops.c free-standing

This test includes stdint.h (via stdatomic.h), which might include system
headers (and that might not work, depending on the system configuration).
Attempting to fix llvm-clang-lld-x86_64-debian-fast.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218960 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Add an additional test for empty structs in C

Empty structs in C differ from those in C++.
- C++ requires that empty types have size 1; alignment requirements may
  increase the size of the struct.
- The C implementation doesn't let empty structs have a size under 4
  bytes.  Again, alignment requirements may increase the struct's size.

Add a test to stress these differences.

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