Default ordinals were assigned in EdataPass, and the assigned values were
then discarded in the pass. No code other than EdataPass would not be able
to get all of the information about ordinals. That's not ideal since I'm
writing code to emit an Import Library file, which also needs ordinals.

This is a patch to move the code to assign default ordinals from EdataPass
to LinkingContext::verify(), so that assigned ordinals will be available
anywhere.

No functionality change.

llvm-svn: 197797

Reported-by: Dmitry N. Mikushin <maemarcus@gmail.com>
llvm-svn: 197796

FormatNavigator has long stopped navigating anything - the generation of possible formatters matches is now done elsewhere
So, rename the class for what it truly is: a FormattersContainer
Also do a bunch of related text substitutions in the interest of overall naming clarity

llvm-svn: 197795

Further:

  o ensure that the header is properly readable even on smaller screen sizes.
  o Shorten the table of contents of the documentation section.

llvm-svn: 197794

llvm-svn: 197793

Recently, support for krait cpu was added. This commit extends getHostCPUName()
to return krait as cpu for the APQ8064 (a Krait 300).

llvm-svn: 197792

If we happen to eliminate every case in a switch that has branch
weights, we currently try to create metadata for the one remaining
branch, triggering an assert. Instead, we need to check that the
metadata we're trying to create is sensible.

llvm-svn: 197791

llvm-svn: 197790

llvm-svn: 197789

llvm-svn: 197788

The .pool directive is an alias for the .ltorg directive used to create a
literal pool.  Simply treat .pool as if .ltorg was passed.

llvm-svn: 197787

Since r197684, "install/bin/llvm-config --obj-root" hasn't shown the build tree. The builder was finding utils in the build tree, from the installed tree.

I will revert this after dragonegg builder would be tweaked not to use installed llvm-config.

llvm-svn: 197786

Before:
  SomeFunction(L"A" L"B");

After:
  SomeFunction(L"A"
               L"B");

llvm-svn: 197785

v2:
  - Fix typo.

Reviewed-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 197784

v2: Add ftrunc->TRUNC pattern instead of replacing int_AMDGPU_trunc
v3: move ftrunc pattern next to TRUNC definition, it's available since R600

Patch By: Jan Vesely

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 197783

the moment.

llvm-svn: 197782

llvm-svn: 197781

assert that this is so.

llvm-svn: 197780

llvm-svn: 197777

when you want to have the full list of addresses for a particular CU or
when you have multiple modules linked together and can't depend upon the
ordering of a single CU for begin/end ranges.

llvm-svn: 197776

of Objective-C classes are completed, and that
variables of Objective-C types have their types
completed when the variables are reported.

This fixes a long-standing issue where ivars did
not show up correctly on 32-bit OS X.

<rdar://problem/12184093> 

llvm-svn: 197775

specify a pointer size until code gen.  So we just
make all our pointer-sized integer literals 64-bit.
That doesn't seem to hurt anything.

llvm-svn: 197774

LLVM's early days.  Today LLVM IR is always target-specific.

llvm-svn: 197772

llvm-svn: 197771

llvm-svn: 197770

OpenCL C lang says that trunc rounds towards zero.
llvm.trunc.* intrinsic rounds to integer not larger in magnitude.
These definitions are equivalent.

Patch by: Jan Vesely

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 197769

That's what it actually means, and with 16-bit support it's going to be
a little more relevant since in a few corner cases we may actually want
to distinguish between 16-bit and 32-bit mode (for example the bare 'push'
aliases to pushw/pushl etc.)

Patch by David Woodhouse

llvm-svn: 197768

llvm-svn: 197767

This is to make it available so the static analyzer can use it.

llvm-svn: 197766

Patch by Laszlo Nagy!

llvm-svn: 197765

This caused some crazy crashes involving std::unordered_map being
deserialized from a PCH file and then template instantiation requiring
an explicit instantiation location; unfortunately I don't really know
how to come up with a minimal test case.

llvm-svn: 197764

llvm-svn: 197763

llvm-svn: 197762

The original code was not completely correct, but a form of
this check is necessary to avoid an infinite recursion on
some unwind cases where a function unwinds to itself with the
same CFA.  Ashok thought the recursion would be caught in
RegisterContextLLDB but this one isn't - we still need it here.
<rdar://problem/15664282> 

llvm-svn: 197761

llvm-svn: 197760

llvm-svn: 197759

llvm-svn: 197758

llvm-svn: 197757

llvm-svn: 197756

files to tell if they were changed since the last time we have computed the
preamble

We used to check only the buffer size, so if the new remapped buffer has the
same size as the previous one, we would think that the buffer did not change,
and we did not rebuild the preambule, which sometimes caused us to crash.

llvm-svn: 197755