The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169219

Have clang use LLVM IR's fast-math flags when in FastMath or FiniteMathOnly modes. Test cases included.

llvm-svn: 169191

llvm-svn: 169187

after its lifetime has ended!

llvm-svn: 169170

Add Clang flags -fsanitize-blacklist and -fno-sanitize-blacklist. Make this flag usable for ASan. Blacklisting can be used to disable sanitizer checks for particular file/function/object.

llvm-svn: 169144

llvm-svn: 169138

llvm-svn: 169124

llvm-svn: 169114

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.

llvm-svn: 169092

llvm-svn: 169041

llvm-svn: 169037

llvm-svn: 168959

1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.

llvm-svn: 168950

Among other differences, GCC accepts

  typedef int IA[];
  typedef int A10[10];
  static A10 *f(void);
  static IA  *f(void);
  void g(void) {
    (void)sizeof(*f());
  }

but clang used to reject it with:

  invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')

The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.

Doing the type merging required some extra fixes:
  * Use the type from the function type in initializations, even if an parameter
    is available.
  * Fix the merging of the noreturn attribute in function types.
  * Make CodeGen  handle the fact that an parameter type can be different from
    the corresponding type in the function type.

llvm-svn: 168895

in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433

llvm-svn: 168825

rdar://12723368

llvm-svn: 168821

the original parameter or return type.

Since we do not accurately represent the data fields of a union, we should not
directly load or store a union type.

As an exmple, if we have i8,i8, i32, i32 as one field type and i32,i32 as
another field type, the first field type will be chosen to represent the union.
If we load with the union's type, the 3rd byte and the 4th byte will be skipped.

rdar://12723368

llvm-svn: 168820

llvm-svn: 168782

objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a 
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570

llvm-svn: 168740

Introduces new sanitizer "unsigned-integer-overflow".

llvm-svn: 168701

ELF ABI.

Complex values are to be passed in registers as though the real and
imaginary parts were passed as separate parameters.  Prior to this
patch, complex values were passed as byval aggregates.  It turns out
that specifying getDirect() for all complex types when classifying the
argument type results in the desired behavior.

The new Clang test case verifies that the correct LLVM IR is generated
for caller and callee for each of the underlying types for _Complex.

llvm-svn: 168673

MSPGCC renamed ISR vectors from vector_<address> to __isr_<number>. This patch makes Clang reflect this scheme.
Patch by Job Noorman!

llvm-svn: 168598

llvm-svn: 168510

llvm-svn: 168355

Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.

llvm-svn: 168260

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.

No functionality changes are intended here (they will come when the predicates
start producing the right answers...).

llvm-svn: 168119

Make sure CodeGenTypes correctly reconverts function types.  Fixes PR14355, a crash in IR generation.

llvm-svn: 168112

llvm-svn: 168047

llvm-svn: 168041

more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.

llvm-svn: 168027

type as written from the ParmVarDecl; it's unclear whether the standard
(C99 6.9.1p10) requires this, but we're following the precedent set by gcc,
and hopefully nobody will ever ask about this again.

PR9559 / <rdar://problem/12621983>.

llvm-svn: 167985

which is not coincidentally the only place it works, either (because
of how it tests for EH_TYPE symbols).

llvm-svn: 167935

llvm-svn: 167934

llvm-svn: 167932

variables captured in a block. // rdar://12184410

llvm-svn: 167931

Patch by Jonathan Schleifer.

llvm-svn: 167925

temporarily since it breaks the gdb bots.

This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.

llvm-svn: 167887

If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>

llvm-svn: 167807

PR11777.

llvm-svn: 167802

lower 24bit is currently being used.

llvm-svn: 167678