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: http://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: http://llvm.org/svn/llvm-project/cfe/trunk@218910 91177308-0d34-0410-b5e6-96231b3b80d8
Reflowing some comments, NFC.

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