llvm-svn: 136727

but it solves a layering violation since things in Support are not supposed to
use things in Transforms.

llvm-svn: 136726

has a single element.  This disables the warning in cases where
there is a clear bug, but this is really rare (who uses arrays
with one element?) and it also silences a large class of false
positive issues with C89 code that is using tail padding in structs.

A better version of this patch would detect when an array is in
a tail position in a struct, but at least patch fixes the huge
false positives that are hitting postgres and other code.

llvm-svn: 136724

llvm-svn: 136723

llvm-svn: 136722

llvm-svn: 136721

I did not take the patch for ClangExpressionParser.cpp since there was a
recent change by Peter for the same line.  Feel free to disagree. :-)

Reference:
----------------------------------------------------------------------
r136580 | pcc | 2011-07-30 15:42:24 -0700 (Sat, 30 Jul 2011) | 3 lines

Add reloc arg to standard JIT createJIT()

Fixes non-__APPLE__ build.  Patch by Matt Johnson!
----------------------------------------------------------------------

Also, I ignore the part of the patch to remove the RegisterContextDarwin*.h/.cpp.

llvm-svn: 136720

enough to offer to investigate the underlying issue.  Thanks to Doug for his
assistance as well.

llvm-svn: 136719

llvm-svn: 136718

statement inside a block. // rdar://9878420

llvm-svn: 136717

externally visable, create a local symbol to use in the CFE. If not, use the
function label itself.

Fixes PR10420.

llvm-svn: 136716

llvm-svn: 136713

The testcase looks extremely fragile, so I'm adding an assertion which should catch any cases like this.

llvm-svn: 136711

Someone with more cmake experience want to throw me a bone? :)

llvm-svn: 136709

by eliminating the type ID from constructor, destructor, and
conversion function names. There are several reasons for this change:
  - A given type (say, int*) isn't guaranteed to have a single, unique
  type ID within a chain of PCH files. Hence, we could end up hashing
  based on the wrong type ID, causing name lookup to fail.

  - The mapping from types back to type IDs required one DenseMap
  entry for every type that was ever deserialized, which was an
  unacceptable cost to support just the name lookup of constructors,
  destructors, and conversion functions. Plus, this mapping could
  never actually work with chained or multiple PCH, based on the first
  bullet.

Once we have eliminated the type from the hash function, these
problems go away, as does my horrible "reverse type remap" hack, which
was doomed from the start (see bullet #1 above) and far too
complicated. 

However, note that removing the type from the hash function means that
all constructors, destructors, and conversion functions have the same
hash key, so I've updated the caller to double-check that the
declarations found have the appropriate name.

llvm-svn: 136708

Fix the broken encodings for the VFP vmov.f32 and vmov.f64 instructions, as well as the comments that explain them incorrectly.

llvm-svn: 136707

[analyzer] Drastically simplify ExprEngine::VisitInitListExpr() by assuming all initializer expressions have already been evaluated.

llvm-svn: 136706

llvm-svn: 136705

Use a more descriptive name so the code is more self-documenting.

llvm-svn: 136704

llvm-svn: 136703

information including the fully preprocessed source file(s) and command line 
arguments.  The developer is asked to attach this diagnostic information to a 
bug report.
rdar://9575623

llvm-svn: 136702

Following up the earlier refactoring/cleanup work by fixing up how we manage the virtual files the ASTReader has to handle.  Specifically, this occurs when the reader is reading AST files that were created in memory and not written to disk.  For example, when a user creates a chained PCH using command line flags.  These virtual files are stored in MemoryBuffers in ChainIncludeSource.cpp, and then read back in by the ASTReader.  This patch moves the management of these buffers into the ModuleManager, so that it becomes the authority on where these buffers are located.

llvm-svn: 136697

Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format
Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers:
 - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory),
   if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target)
   pointer to the Python code
Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used:
 - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target

llvm-svn: 136695

KeychainAPI checker: only check the paths on which the allocator function returned noErr. (+ minor cleanup)

llvm-svn: 136694

reader. This scheme permits an AST file to be loaded with its type IDs
shifted anywhere in the type ID space. 

At present, the type indices are still allocated in the same boring
way they always have been, just by adding up the number of types in
each PCH file within the chain. However, I've done testing with this
patch by randomly sliding the base indices at load time, to ensure
that remapping is occurring as expected. I may eventually formalize
this in some testing flag, but loading multiple (non-chained) AST
files at once will eventually exercise the same code.

There is one known problem with this patch, which involves name lookup
of operator names (e.g., "x.operator int*()") in cases where multiple
PCH files in the chain. The hash function itself depends on having a
stable type ID, which doesn't happen with chained PCH and *certainly*
doesn't happen when sliding type IDs around. We'll need another
approach. I'll tackle that next.

llvm-svn: 136693

This unbreaks some tests.

llvm-svn: 136692

  shuffle (scalar_to_vector (load (ptr + 4))), undef, <0, 0, 0, 0>
To:
  shuffle (vload ptr)), undef, <1, 1, 1, 1>
Fix PR10494

llvm-svn: 136691

llvm-svn: 136690

to compile a working hello world on FreeBSD/PPC32.

llvm-svn: 136689

reader statistics), to show the local-to-global mappings. The only
such mapping we have (at least, for now) is for source location
offsets.

llvm-svn: 136687

all of the kinds of IDs that can be offset. No effectively
functionality change; this is preparation for adding remapping for
IDs.

llvm-svn: 136686

Contributed by: Sebastian Pop <sebpop@gmail.com>

llvm-svn: 136685

llvm-svn: 136684

The 'unwind' function is going away with the new EH rewrite. This is step 0 in
keeping front-ends from using it.

llvm-svn: 136683

llvm-svn: 136682

llvm-svn: 136681

llvm-svn: 136680

llvm-svn: 136679

No functional change.

llvm-svn: 136678

llvm-svn: 136677