llvm-svn: 196399

When parsing ignored attribute arguments, presuming the first argument is an unresolved identifier the same way that we do for unknown arguments. This resolves PR18075, where we regressed the handling of OpenBSD's bounded attribute.

llvm-svn: 196387

I'd misunderstood getIndirect() to mean that the argument should be passed
as a pointer at the ABI level, with the ByVal argument choosing caller-copy
semantics over no-caller-copy (callee-copy-on-write) semantics.  But
getIndirect(x) actually means that x is passed by pointer at the IR
level but (at least on all other targets I looked at) directly at the
ABI level.  getIndirect(x, false) selects a pointer to a caller-made
copy, which is what SystemZ was aiming for.

This fixes a miscompilation of c-index-test.  Structure arguments were being
passed by pointer, but no copy was being made, so a write in the callee
stomped over a caller's local variable.

llvm-svn: 196370

We would lose track of the mangling number assigned to the original
declaration which would cause us to create manglings that didn't match
the Itanium C++ specification.

e.g. Two static fields with the same name inside of a function template
would receive the same mangling with LLVM fixing up the second field so
they wouldn't collide.  This would create an incompatibility with other
compilers following the Itanium ABI.

I've confirmed that the new mangling is identical to the ones generated
by icc and gcc.

N.B. This was uncovered while working on Microsoft mangler.

llvm-svn: 196368

llvm-svn: 196361

llvm-svn: 196359

This patch fixes PR16989.

llvm-svn: 196352

In delayed template parsing mode, adjust the template depth counter for each template parameter list associated with an out of line member template specialization.

llvm-svn: 196351

llvm-svn: 196350

llvm-svn: 196349

clang/test/CodeGen/builtins-nvptx.c: Prune "REQUIRES: nvptx64-registered-target". "nvptx" should imply it.

llvm-svn: 196348

In trunk, we can use features as below:

  aarch64-registered-target
  hexagon-registered-target
  msp430-registered-target
  r600-registered-target
  systemz-registered-target
  xcore-registered-target

Each of them, as below, implies corresponding subtargets:

  arm-registered-target   -- arm, thumb
  mips-registered-target  -- mips, mips64, mips64el, mipsel
  nvptx-registered-target -- nvptx, nvptx64
  sparc-registered-target -- sparc, sparcv9
  x86-registered-target   -- x86, x86-64

They will be renamed:

  cppbackend-registered-target -- was "cpp". Unused in trunk.
  powerpc-registered-target -- was "ppc32", "ppc64" and "ppc64le".

The feature "asserts" is also taken from llvm-config.

llvm-svn: 196347

to a variable template specialization.

llvm-svn: 196337

llvm-svn: 196335

simple-template-ids (eg, 'operator+<int>') in weird places.

llvm-svn: 196333

override all of the designated initializers of its superclass.

llvm-svn: 196319

super another initializer and when the implementation does not delegate to
another initializer via a call on 'self'.

A secondary initializer is an initializer method not marked as a designated
initializer within a class that has at least one initializer marked as a
designated initializer.

llvm-svn: 196318

super an initializer that is not a designated one or any initializer on self.

llvm-svn: 196317

an init method that is a designated initializer for the superclass.

llvm-svn: 196316

It only applies to methods of init family in an interface declaration.

llvm-svn: 196314

Before, there SourceManager would not return a FileEntry for a
SourceLocation of a macro expansion (if the header name itself is
defined in a macro). We'd then fallback to assume that the module
currently being built is the including module. However, in this case we
are actually interested in the spelling location of the filename loc in
order to derive the including module.

llvm-svn: 196311

return void expression. // rdar://15366494
pr17759.

llvm-svn: 196296

llvm-svn: 196287

llvm-svn: 196286

llvm-svn: 196285

llvm-svn: 196284

llvm-svn: 196282

llvm-svn: 196281

llvm-svn: 196280

llvm-svn: 196279

llvm-svn: 196278

llvm-svn: 196277

llvm-svn: 196276

llvm-svn: 196275

llvm-svn: 196213

clang converts keywords to identifiers for compatibility with various system
headers such as GNU libc.

Implement a -Wkeyword-compat extension warning to diagnose those cases. The
warning is on by default but will generally be ignored in system headers. It
can however be enabled globally to aid standards conformance testing.

This also changes the __uptr keyword avoidance from r195710 to no longer
special-case system headers, bringing it in line with other similar workarounds
in clang.

Implementation returns bool for symmetry with token annotation functions.

Some examples:

warning: keyword '__is_pod' will be treated as an identifier for the remainder of the translation unit [-Wkeyword-compat]
struct __is_pod

warning: keyword '__uptr' will be treated as an identifier here [-Wkeyword-compat]
union w *__uptr;

llvm-svn: 196212

E.g. int64x1_t vcvt_s64_f64(float64x1_t a) -> FCVTZS Dd, Dn

llvm-svn: 196211

E.g. float64x1_t vadd_f64(float64x1_t a, float64x1_t b) -> FADD Dd, Dn, Dm.

llvm-svn: 196209

Fixed vcopy_laneq_f64 intrinsic implementation.

llvm-svn: 196206

This is a duplicate implementation.
E.g. this patch defines:
     float64_t vabd_f64(float64_t a, float64_t b)
But there is already a similar intrinsic "vabdd_f64" with the same types.
Also, this intrinsic will be conflicted to the vector type intrinsic as following(Which is implemented by me and will be committed to trunk):
     float64x1_t vabd_f64(float64x1_t a, float64x1_t b).
Two functions shouldn't have a same name in arm_neon.h.
According to ARM ACLE document, such vabd_f64 with float64_t is not existing.
So I revert this commit.

llvm-svn: 196205