DEBUG_RUNTIME Makefile variable to pass -g to gcc when building LLVM's objects.
Without this, it's very hard to debug crashes that happen in Release-Asserts
mode but not Debug mode.

llvm-svn: 82775

llvm-svn: 82774

llvm-svn: 82773

llvm-svn: 82772

llvm-svn: 82771

llvm-svn: 82770

For the AAPCS ABI, SP must always be 4-byte aligned, and at any "public
interface" it must be 8-byte aligned.  For the older ARM APCS ABI, the stack
alignment is just always 4 bytes.  For X86, we currently align SP at
entry to a function (e.g., to 16 bytes for Darwin), but no stack alignment
is needed at other times, such as for a leaf function.

After discussing this with Dan, I decided to go with the approach of adding
a new "TransientStackAlignment" field to TargetFrameInfo.  This value
specifies the stack alignment that must be maintained even in between calls.
It defaults to 1 except for ARM, where it is 4.  (Some other targets may
also want to set this if they have similar stack requirements. It's not
currently required for PPC because it sets targetHandlesStackFrameRounding
and handles the alignment in target-specific code.) The existing StackAlignment
value specifies the alignment upon entry to a function, which is how we've
been using it anyway.

llvm-svn: 82767

Likewise for constant inbounds GEP.

llvm-svn: 82763

llvm-svn: 82762

llvm-svn: 82761

llvm-svn: 82760

llvm-svn: 82759

llvm-svn: 82758

llvm-svn: 82757

llvm-svn: 82756

are now running properly from within CMake.

llvm-svn: 82755

llvm-svn: 82754

Previously, it treated GV+28 GV+0 as different bases, and assumed they could
not alias.

llvm-svn: 82753

Turn on 'RegionStore' as the default store manager both for 'clang --analyze' and 'scan-build'.  Leave 'BasicStore' as the default store manager in 'clang-cc'.  While there are still known warts with RegionStore, it's ready to be tested by general users.

llvm-svn: 82752

llvm-svn: 82751

this adjustment does not change the direction or the signs of the object
offsets, and the details of the offset calculations can be target-specific.
Also mention that for most targets this value is only used to generate debug
info.

llvm-svn: 82750

llvm-svn: 82749

value-dependent. Audit (and fixed) all calls to
Expr::isNullPointerConstant() to provide the correct behavior with
value-dependent expressions. Fixes PR5041 and a crash in libstdc++
<locale>.

In the same vein, properly compute value- and type-dependence for
ChooseExpr. Fixes PR4996.

llvm-svn: 82748

llvm-svn: 82747

Who would have thought that empty classes were so tricky? Handle cases where an empty virtual base class needs to be moved aside because it conflicts with the first field.

llvm-svn: 82746

for a ObjC class with an ivar of weak self type.

llvm-svn: 82745

llvm-svn: 82744

instructions. This fixes a PowerPC bug exposed by some unrelated
changes I'm working on.

llvm-svn: 82743

llvm-svn: 82742

Fix <rdar://problem/7249327> by allowing silent conversions between signed and unsigned integer values for symbolic values.  This is an intermediate solution (i.e. hack) until we support extension/truncation of symbolic integers.

llvm-svn: 82737

llvm-svn: 82736

llvm-svn: 82735

interest for this, as it currently reserves a register rather than using
the scavenger for matierializing constants as needed.

Instead of scavenging registers on the fly while eliminating frame indices,
new virtual registers are created, and then a scavenged collectively in a
post-pass over the function. This isolates the bits that need to interact
with the scavenger, and sets the stage for more intelligent use, and reuse,
of scavenged registers.

For the time being, this is disabled by default. Once the bugs are worked out,
the current scavenging calls in replaceFrameIndices() will be removed and
the post-pass scavenging will be the default. Until then,
-enable-frame-index-scavenging enables the new code. Currently, only the
Thumb1 back end is set up to use it.

llvm-svn: 82734

llvm-svn: 82733

complete (or, possibly causing template instantiation).

Test this via some explicit specializations of member functions.

llvm-svn: 82732

llvm-svn: 82731

llvm-svn: 82730

delete a few blank lines.

llvm-svn: 82729

first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks

There are many caveats here:
  - We completely and totally drop any explicitly-specified template
  arguments on the floor
  - We don't diagnose any of the extra semantic things that we should
  diagnose. 
  - I haven't looked to see that we're getting the right linkage for
  explicit specializations

On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.

llvm-svn: 82728

llvm-svn: 82727