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

a memory buffer instead of only a filename.

llvm-svn: 167627

us from having to make any backend changes.

llvm-svn: 167623

rdar://12340498

llvm-svn: 167619

at whether the *selected* constructor would be trivial rather than considering
whether the array's element type has *any* non-trivial constructors of the
relevant kind.

llvm-svn: 167562

captured block variable layout meta-data. No intended change
in functionality.

llvm-svn: 167549

a bug in the inliner still causes the wrong thing to happen at -O2 and above
(PR14116).

llvm-svn: 167534

This is useful because unnamed bitfields can have effects on the
offsets which are not otherwise reflected in the DWARF information.

<rdar://problem/12629719>

llvm-svn: 167503

works between the modules.
No functionality change on Darwin/Windows.
This fixes PR11480.

llvm-svn: 167496

coverage of this code is.

llvm-svn: 167495

llvm-svn: 167487

llvm-svn: 167476

disabling byval, we set realign to true.

It will perform an aligned alloca, and call memcpy to copy the byval
argument to the local variable.
Change the size threshold back to 64 bytes.

rdar://12596507

llvm-svn: 167440

llvm-svn: 167437

refactor the code.

llvm-svn: 167436

Classify the INT_MIN/-1 check as -fsanitize=signed-integer-overflow, not as -fsanitize=divide-by-zero.

llvm-svn: 167433

llvm-svn: 167431

token. This is important because the first token could actually be
after an #include that triggers a module import, which might use
either Sema or the AST consumer before it would have been initialized.

llvm-svn: 167423

the type alignment of the byval argument. This patch will disable byval in this case,
it also increases the size threshold for turning on byval.

A backend fix will be attempted.

rdar://12596507

llvm-svn: 167416

checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.

llvm-svn: 167413

*Sanitizer to Sanitize* in preparation for later patches.

llvm-svn: 167405

zero-extended to 64 bits.  This information is currently provided to
the back end by setting "signext" or "zeroext" attributes.  However,
this is done only for integer types *smaller* than i32, not for i32
itself.  This causes clang to generate code violating the ABI, which
results in a failure of the tramp3d-v4 test case (due to calling a
system library routine without ABI-required extension).

This patch implements custom versions of classifyArgumentType and
classifyReturnType for PPC64_SVR4_ABIInfo, which are the same as the
default versions except that they also classify "int" and "unsigned int"
as types needing extending.  This fixed tramp3d-v4 on PowerPC64.

llvm-svn: 167393

well as couple of tests which were not being excercised because of TYPOs.

llvm-svn: 167374

llvm-svn: 167336

mrr mode.

llvm-svn: 167331

llvm-svn: 167308

llvm-svn: 167266

llvm-svn: 167261

llvm-svn: 167260

separate functions, since they share essentially no code.

llvm-svn: 167259