This would cause internal symbols that are only referenced by global initializers to be removed.

This reverts commit 194219.

llvm-svn: 194304

This reverts commit 194219.

llvm-svn: 194303

llvm-svn: 194219

The BlockAddress doesn't have access to the correct basic blocks until the
functions have been cloned. This causes the BlockAddress to point to the old
values. Just wait until the functions have been cloned before copying the
initializers.
PR13163

llvm-svn: 194218

ErrorOr had quiet a bit of complexity and indirection to be able to hold a user
type with the error.

That feature is not used anymore. This patch removes it, it will live in svn
history if we ever need it again.

If we do need it again, IMHO there is one thing that should be done
differently: Holding extra info in the error is not a property a function also
returning a value or not. The ability to hold extra info should be in the error
type and ErrorOr templated over it so that we don't need the funny looking
ErrorOr<void>.

llvm-svn: 194030

llvm-svn: 193734

The function verifyFunction() in lib/IR/Verifier.cpp misses some
calls. It creates a temporary FunctionPassManager that will run a
single Verifier pass. Unfortunately, FunctionPassManager is no
PassManager and does not call doInitialization() and doFinalization()
by itself. Verifier does important tasks in doInitialization() such as
collecting type information used to check DebugInfo metadata and
doFinalization() does some additional checks. Therefore these checks
were missed and debug info couldn't be verified at all, it just
crashed if the function had some.

verifyFunction() is currently not used in llvm unless -debug option is
enabled, and in unittests/IR/VerifierTest.cpp

VerifierTest had to be changed to create the function in a module from
which the type debug info can be collected.

Patch by Michael Kruse.

llvm-svn: 193719

startswith_lower is ocassionally useful and I think worth adding.
endwith_lower is added for completeness.

Differential Revision: http://llvm-reviews.chandlerc.com/D2041

llvm-svn: 193706

the case [x, INT_MIN) was not handled optimally

llvm-svn: 193694

Based on D2050 by Timur Iskhodzhanov.

llvm-svn: 193619

DWARF parser: Use ArrayRef to represent form sizes and simplify DWARFDIE::extractFast() interface. No functionality change.

llvm-svn: 193560

Summary:
Use DWARF4 table of form classes to fetch attributes from DIE
in a more consistent way. This shouldn't change the functionality and
serves as a refactoring for upcoming change: DW_AT_high_pc has different
semantics depending on its form class.

Reviewers: dblaikie, echristo

Reviewed By: echristo

CC: echristo, llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D1961

llvm-svn: 193553

llvm-svn: 193550

llvm-svn: 193432

llvm-svn: 193431

llvm-svn: 193429

llvm-svn: 193427

llvm-svn: 193363

llvm-svn: 193361

llvm-svn: 193350

llvm-svn: 193344

Includes a test case/FIXME demonstrating a bug/limitation in pointer to
member hashing. To be honest I'm not sure why we don't just always use
summary hashing for referenced types... but perhaps I'm missing
something.

llvm-svn: 193175

DWARF Type Hashing: Include reference and rvalue reference type in the declarable summary hashing path

More support for 7.25 Part 5.

llvm-svn: 193129

There are several other tag types that need similar handling but to
ensure test coverage they'll be coming incrementally.

llvm-svn: 193126

llvm-svn: 193125

And add the 'Test' suffix so the test case name matches the file name.

llvm-svn: 193119

This uses a map, keeping the type DIE numbering separate from the DIEs
themselves - alternatively we could do things the way GCC does if we
want to add an integer to the DIE type to record the numbering there.

llvm-svn: 193105

llvm-svn: 192924

llvm-svn: 192856

This allows us to produce the same hash as GCC for at least some simple
examples.

llvm-svn: 192855

GTest assumes the left hand side of the assert is the expectation and
the right hand side is the test result. It's easier to read gtest
failures when these things are ordered correctly.

llvm-svn: 192854

llvm-svn: 192836

This patch fixes a small mistake in MCDataAtom::addData() where it doesn't ever
call remap():

-  if (Data.size() > Begin - End - 1)
+  if (Data.size() > End + 1 - Begin)
     remap(Begin, End + 1);

This is currently not visible because of another bug is the disassembler, so
the patch includes a unit test.

Patch by Stephen Checkoway.

llvm-svn: 192823

Before this patch we would assert when building llvm as multiple shared
libraries (cmake's BUILD_SHARED_LIBS). The problem was the line

if (T.AsmStreamerCtorFn == Target::createDefaultAsmStreamer)

which returns false because of -fvisibility-inlines-hidden. It is easy
to fix just this one case, but I decided to try to also make the
registration more strict. It looks like the old logic for ignoring
followup registration was just a temporary hack that outlived its
usefulness.

This patch converts the ifs to asserts, fixes the few cases that were
registering twice and makes sure all the asserts compare with null.

Thanks for Joerg for reporting the problem and reviewing the patch.

llvm-svn: 192803

Also minor using namespace move so it's not hard-up against the function
definition and outside the namespace as is usual.

llvm-svn: 192744

llvm-svn: 192042

This should fix the i386 Darwin build-bot.

llvm-svn: 191840

This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804

- New ProcessInfo class to encapsulate information about child processes.
- Generalized the Wait() to support non-blocking wait on child processes.
- ExecuteNoWait() now returns a ProcessInfo object with information about
  the launched child. Users will be able to use this object to
  perform non-blocking wait.
- ExecuteNoWait() now accepts an ExecutionFailed param that tells if execution
  failed or not.

These changes will allow users to implement basic process parallel
tools.

Differential Revision: http://llvm-reviews.chandlerc.com/D1728

llvm-svn: 191763

llvm-svn: 191723