llvm-svn: 286563

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

Differential Revision: https://reviews.llvm.org/D26481

llvm-svn: 286561

Include the cctype header to try to fix windows bots.

llvm-svn: 286558

This is a replacement to binutils' string tool.  It prints strings found in a
binary (object file, executable, or archive library).  It is rather bare and
not functionally equivalent, however, it lays the groundwork necessary for the
strings tool, enabling iterative development of features to reach feature
parity.

llvm-svn: 286556

../tools/llvm-extract/llvm-extract.cpp: In function ‘int main(int, char**)’:
warning: ISO C++ forbids zero-size array ‘argv’ [-Wpedantic]

GCC reference bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61259

llvm-svn: 286396

Differential Revision: https://reviews.llvm.org/D26439

llvm-svn: 286382

Summary:
All changes are pretty straight-forward. I chose to use TimePoints with
second precision, as that is all that seems to be required here.

Reviewers: friss, zturner

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D25908

llvm-svn: 286358

This reverts commit r286297.
Introduces a dependency from libAnalysis to libObject, which I missed
during the review.

llvm-svn: 286329

The BitcodeReader no longer produces BitcodeDiagnosticInfo diagnostics.
The only remaining reference was in the gold plugin; the code there has been
dead since we stopped producing InvalidBitcodeSignature error codes in r225562.
While at it remove the InvalidBitcodeSignature error code.

llvm-svn: 286326

Previously support had been added for using CodeViewRecordIO
to read (deserialize) CodeView type records.  This patch adds
support for writing those same records.  With this patch,
reading and writing of CodeView type records finally uses a single
codepath.

Differential Revision: https://reviews.llvm.org/D26253

llvm-svn: 286304

Summary:
This patch uses the same approach added for inline asm in r285513 to
similarly prevent promotion/renaming of locals used or defined in module
level asm.

All static global values defined in normal IR and used in module level asm
should be included on either the llvm.used or llvm.compiler.used global.
The former were already being flagged as NoRename in the summary, and
I've simply added llvm.compiler.used values to this handling.

Module level asm may also contain defs of values. We need to prevent
export of any refs to local values defined in module level asm (e.g. a
ref in normal IR), since that also requires renaming/promotion of the
local. To do that, the summary index builder looks at all values in the
module level asm string that are not marked Weak or Global, which is
exactly the set of locals that are defined. A summary is created for
each of these local defs and flagged as NoRename.

This required adding handling to the BitcodeWriter to look at GV
declarations to see if they have a summary (rather than skipping them
all).

Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to
ensure that an MCAsmParser is available, otherwise the module asm parse
would silently fail. Initialized the asm parser in the opt tool for use
in testing this fix.

Fixes PR30610.

Reviewers: mehdi_amini

Subscribers: johanengelen, krasin, llvm-commits

Differential Revision: https://reviews.llvm.org/D26146

llvm-svn: 286297

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.

The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.

Differential Revision: https://reviews.llvm.org/D26384

llvm-svn: 286214

As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html

Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.

At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.

Differential Revision: https://reviews.llvm.org/D26259

llvm-svn: 286207

insufficient to populate the expected struct. Prior to this we already
bailed out of the routine when this situation comes up, so none of this
code had any effect.

If someone wants to bring it back to handle these cases, fixing the
earlier conditions and adding the necessary test cases that actually
exercises it, they can always revert this and go from there.

Both of these were noticed by PVS-Studio due to the identical (dead)
condition.

llvm-svn: 285989

in llvm-objdump for Mach-O files add the printing of the
ARM_THREAD_STATE64 in the same format as
otool-classic(1) on darwin.

To do this the 64-bit ARM general tread state
needed to be defined in include/llvm/Support/MachO.h .

rdar://28985800

llvm-svn: 285967

llvm-svn: 285955

Issue found by inspection.

llvm-svn: 285951

llvm-svn: 285942

llvm-readobj.

Another bug caught by PVS-Studio.

It'd be nice to actually have a test for this, but I found it by
inspection from PVS-Studio.

llvm-svn: 285937

llvm-svn: 285920

llvm-svn: 285910

llvm-svn: 285905

llvm-svn: 285887

llvm-svn: 285853

Using a pattern similar to that of YamlIO, this allows
us to have a single codepath for translating codeview
records to and from serialized byte streams.  The
current patch only hooks this up to the reading of
CodeView type records.  A subsequent patch will hook
it up for writing of CodeView type records, and then a
third patch will hook up the reading and writing of
CodeView symbols.

Differential Revision: https://reviews.llvm.org/D26040

llvm-svn: 285836

Reviewers: beanz, lattner, jlebar

Subscribers: jholewinski, llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D26235

llvm-svn: 285832

Have it return a ErrorOr<Range> and delete section_begin and
section_end.

llvm-svn: 285807

As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106595.html

This change also fixes an API oddity where BitstreamCursor::Read() would
return zero for the first read past the end of the bitstream, but would
report_fatal_error for subsequent reads. Now we always report_fatal_error
for all reads past the end. Updated clients to check for the end of the
bitstream before reading from it.

I also needed to add padding to the invalid bitcode tests in
test/Bitcode/. This is because the streaming interface was not checking that
the file size is a multiple of 4.

Differential Revision: https://reviews.llvm.org/D26219

llvm-svn: 285773

Summary:
This fixes a few things that used to work with a Makefile build, but were broken in cmake.

1. Treat MINGW like a Linux system.
2. The shlib should never contain other shared libraries.

Patch By: Valentin Churavy

Reviewers: axw, beanz

Subscribers: modocache, beanz, mgorny

Differential Revision: https://reviews.llvm.org/D25865

llvm-svn: 285737

Add the necessary definitions for RISC-V ELF files, including relocs. Also 
make necessary trivial change to ELFYaml, llvm-objdump, and llvm-readobj in 
order to work with RISC-V ELFs.

Differential Revision: https://reviews.llvm.org/D23557

llvm-svn: 285708

Summary:
There is no point to importing at -O0, since we won't inline. We should
also disable other cross-module optimizations.

(Plan to backport this fix to the 3.9 branch to fix PR30774)

Reviewers: pcc

Subscribers: johanengelen, mehdi_amini

Differential Revision: https://reviews.llvm.org/D25918

llvm-svn: 285648

DW_TAG_atomic_type was already included in Dwarf.defs and emitted correctly,
however Verifier didn't recognize it as valid.
Thus we introduce the following changes:

  * Make DW_TAG_atomic_type valid tag for IR and DWARF (enabled only with -gdwarf-5)
  * Add it to related docs
  * Add DebugInfo tests

Differential Revision: https://reviews.llvm.org/D26144

llvm-svn: 285624

Fixes PR28488.

Reviewers: rnk, majnemer

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D25834

llvm-svn: 285616

Found by PVS-Studio.

llvm-svn: 285598

Found by PVS-Studio.

llvm-svn: 285597

Modifying DWARFFormValue to remember the DWARFUnit that it was encoded with can simplify the usage of instances of this class. Previously users would have to try and pass in the same DWARFUnit that was used to decode the form value and there was a possibility that a different DWARFUnit might be supplied to the functions that extract values (strings, CU relative references, addresses) and cause problems. This fixes this potential issue by storing the DWARFUnit inside the DWARFFormValue so that this mistake can't be made. Instances of DWARFFormValue are not stored permanently and are used as temporary values, so the increase in size of an instance of DWARFFormValue isn't a big deal. This makes decoding form values more bullet proof and is a change that will be used by future modifications.

https://reviews.llvm.org/D26052

llvm-svn: 285594

llvm-svn: 285592

tools

    Differential Revision: https://reviews.llvm.org/D25861

llvm-svn: 285514

llvm-svn: 285481

This brings the LLI orc-lazy JIT's behavior more closely in-line with LLI's
mcjit bahavior.

llvm-svn: 285413