llvm-svn: 167441

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: 167439

Thanks Jordan.

llvm-svn: 167438

llvm-svn: 167437

refactor the code.

llvm-svn: 167436

This is in preparation for adding "weak" DAG edges, but generally
simplifies the design.

llvm-svn: 167435

llvm-svn: 167434

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

llvm-svn: 167433

it's also setup as 'INTERNAL_TOOL'.

llvm-svn: 167432

llvm-svn: 167431

inlined subroutine ranges.

<rdar://problem/12588579>

llvm-svn: 167430

-fno-address-sanitizer, -fthread-sanitizer, -fno-thread-sanitizer, and
-fcatch-undefined-behavior as deprecated: produce a warning if they are used
pointing to the corresponding -fsanitize= option. In passing add the missing
'-' to some diagnostics.

llvm-svn: 167429

llvm-svn: 167426

reference instead of relying on computing it.

In general, if storage is no issue, it is preferable to deserialize info from
the PCH instead of trying to recompute it after the PCH was loaded.

The incentive to change this now was due to r155303 changing how friend template
classes in dependent contexts are handled; such classes can now be chained to
a previous template class but the computed InjectedClassNameType may be different
due to the extra template parameters from the dependent context.

The new handling requires more investigation but, in the meantime, writing out
InjectedClassNameType fixes PCH issue in rdar://12627738.

llvm-svn: 167425

Unnamed bitfields cause struct layout problems

Synthesize unnamed bitfields when required. Most compilers don't mention unnamed bitfields in the DWARF, so we need to create them to keep clang happy with the types we create from the DWARF. We currently can't do this for ObjC since the DW_AT_bit_offset value for any direct ivars of ObjC classes as the values for these attributes are bogus. A bug has been filed on Clang to fix this, and another bug has been filed on LLDB to make sure we fix the DWARF parser once the clang fix is in by looking the the DW_AT_producer in the compile unit attributes and finding the compiler version and only enabling it for newer versions of clang.

llvm-svn: 167424

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

llvm-svn: 167422

llvm-svn: 167421

that we can model them as separate submodules.

llvm-svn: 167420

 - The whole {File,Source}Manager is built around wanting to pre-determine the
   size of files, so we can't fit this in naturally. Instead, we handle it like
   we do STDIN, where we just replace the main file contents upfront.

llvm-svn: 167419

llvm-svn: 167418

llvm-svn: 167417

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

llvm-svn: 167412

-fno-sanitize=<sanitizers> argument to driver. These allow ASan, TSan, and the
various UBSan checks to be enabled and disabled separately. Right now, the
different modes can't be combined, but the intention is that combining UBSan
and the other sanitizers will be permitted in the near future.

Currently, the UBSan checks will all be enabled if any of them is; that will be
fixed by the next patch.

llvm-svn: 167411

llvm-svn: 167410

possible buffer change with a .macro directive.

rdar://12637628

llvm-svn: 167408

 - We only support this when the client didn't claim to know the file size.

llvm-svn: 167407

*Sanitizer to Sanitize* in preparation for later patches.

llvm-svn: 167405

llvm-svn: 167402

llvm-svn: 167401

Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress).  In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved.  To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.

llvm-svn: 167400

llvm-svn: 167399

While we're here, extend the module map to cover most of the
newly-added instrinsic headers. Only wmmintrin.h is missing, because
it needs to be split into AES/PCLMUL subheaders (as a separate commit).

llvm-svn: 167398

header-search options into the module hash. We're just using
ADT/Hashing.hpp for this, which isn't as cryptographically strong as
I'd like, but it'll do. If someone contributes (say) and MD4
implementation, we'd happily switch to that.

llvm-svn: 167397

to be extended to a full register.   This is modeled in the IR by marking
the return value (or argument) with a signext or zeroext attribute.

However, while these attributes are respected for function arguments,
they are currently ignored for function return values by the PowerPC
back-end.  This patch updates PPCCallingConv.td to ask for the promotion
to i64, and fixes LowerReturn and LowerCallResult to implement it.

The new test case verifies that both arguments and return values are
properly extended when passing them; and also that the optimizers
understand incoming argument and return values are in fact guaranteed
by the ABI to be extended.

The patch caused a spurious breakage in CodeGen/PowerPC/coalesce-ext.ll,
since the test case used a "ret" instruction to create a use of an i32
value at the end of the function (to set up data flow as required for
what the test is intended to test).  Since there's now an implicit
promotion to i64, that data flow no longer works as expected.  To fix
this, this patch now adds an extra "add" to ensure we have an appropriate
use of the i32 value.

llvm-svn: 167396

llvm-svn: 167395

llvm-svn: 167394