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

llvm-svn: 197754

llvm-svn: 197753

llvm-svn: 197752

This removes a lot of duplicated code.

llvm-svn: 197751

llvm-svn: 197750

llvm-svn: 197748

llvm-svn: 197747

llvm-svn: 197746

llvm-svn: 197745

this commit as the only one on the Blamelist so I quickly reverted this.
However it was actually Nick's change who has since fixed that issue.

Original commit message:

Changed the X86 assembler for intel syntax to work with directional labels.

The X86 assembler as a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.

The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following an Integer.  Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels.  It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.

When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.

rdar://14961158

llvm-svn: 197744

This matches what the configure build does.

Patch by Jan Vesely.

Fixes pr14189.

llvm-svn: 197743

--analyze passes -w, but -cc1 -analyze doesn't. Oops!

llvm-svn: 197741

I have a pending change for clang to use getStringRepresentation to check
that its DataLayout is in sync with llvm's.

getStringRepresentation is not called from llvm itself, so far it is mostly
a debugging aid, so the shorter strings are an independent improvement.

llvm-svn: 197740

llvm-svn: 197739

llvm-svn: 197738

llvm-svn: 197737

llvm-svn: 197736

We dump any non-empty assembler constant pools after a successful
parse of an assembly file that uses the ldr pseudo opcode. These
per-section constant pools should be output in a deterministic order
to ensure that we always generate the same output when printing the
output with an AsmStreamer.

This patch changes the map data struture used to associate a section
with its constant pool to a MapVector to ensure deterministic
output. Because this map type does not support deletion, we now
check that the constant pool is not empty before dumping its entries
and clear the entries after emitting them with the streamer.

llvm-svn: 197735

llvm-svn: 197734

We have assertions for this, but a few edge cases had snuck through where
we were still unconditionally using 'int'.

<rdar://problem/15703011>

llvm-svn: 197733

llvm-svn: 197732

directional labels.  Because it doesn't work for windows :)

llvm-svn: 197731

llvm-svn: 197730

llvm-svn: 197729

The X86 assembler has a separate code to parser the intel assembly syntax
in X86AsmParser::ParseIntelOperand().  This did not parse directional labels.
And if something like 1f was used as a branch target it would get an
"Unexpected token" error.

The fix starts in X86AsmParser::ParseIntelExpression() in the case for
AsmToken::Integer, it needs to grab the IntVal from the current token
then look for a 'b' or 'f' following the Integer.  Then it basically needs to
do what is done in AsmParser::parsePrimaryExpr() for directional
labels.  It saves the MCExpr it creates in the IntelExprStateMachine
in the Sym field.

When it returns to X86AsmParser::ParseIntelOperand() it looks
for a non-zero Sym field in the IntelExprStateMachine and if
set it creates a memory operand not an immediate operand
it would normally do for the Integer.

rdar://14961158

llvm-svn: 197728

The main changes are in:
  include/lld/Core/Reference.h
  include/lld/ReaderWriter/Reader.h
Everything else is details to support the main change.

1) Registration based Readers
Previously, lld had a tangled interdependency with all the Readers.  It would
have been impossible to make a streamlined linker (say for a JIT) which
just supported one file format and one architecture (no yaml, no archives, etc).
The old model also required a LinkingContext to read an object file, which
would have made .o inspection tools awkward.

The new model is that there is a global Registry object. You programmatically 
register the Readers you want with the registry object. Whenever you need to 
read/parse a file, you ask the registry to do it, and the registry tries each 
registered reader.

For ease of use with the existing lld code base, there is one Registry
object inside the LinkingContext object. 


2) Changing kind value to be a tuple
Beside Readers, the registry also keeps track of the mapping for Reference
Kind values to and from strings.  Along with that, this patch also fixes
an ambiguity with the previous Reference::Kind values.  The problem was that
we wanted to reuse existing relocation type values as Reference::Kind values.
But then how can the YAML write know how to convert a value to a string? The
fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace
(e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and
a 16-bit value.  This tuple system allows conversion to and from strings with 
no ambiguities.

llvm-svn: 197727

llvm-svn: 197726

A comment following the "{" of a braced list seems to almost always
refer to the first element of the list and thus should be aligned
to it.

Before (with Cpp11 braced list style):
  SomeFunction({  // Comment 1
                   "first entry",
                   // Comment 2
                   "second entry"});
After:
  SomeFunction({// Comment 1
                "first entry",
                // Comment 2
                "second entry"});

llvm-svn: 197725

llvm-svn: 197724

llvm-svn: 197723

llvm-svn: 197722

Pruning header includes and forward references and fixing comments.

llvm-svn: 197720

llvm-svn: 197719

According to the docs, ThreadLocal<>::get() should return NULL
if no object has been set. This patch makes that the case also for non-thread
builds and adds a very basic unit test to check it.

(This was causing PR18205 because PrettyStackTraceHead didn't get zero-
initialized and we'd crash trying to read past the end of that list. We didn't
notice this so much on Linux since we'd crash after printing all the entries,
but on Mac we print into a SmallString, and would crash before printing that.)

llvm-svn: 197718

Summary:
Allow disabling checks by regex. By default, disable alpha.* checks,
that are not particularly good tested (e.g. IdempotentOperationChecker, see
http://llvm-reviews.chandlerc.com/D2427).

Fixed a bug, that would disable all analyzer checks, when using a regex more
strict, than 'clang-analyzer-', for example --checks='clang-analyzer-deadcode-'.

Added --list-checks to list all enabled checks. This is useful to test specific
values in --checks/--disable-checks.

Reviewers: djasper, klimek

Reviewed By: klimek

CC: cfe-commits, klimek

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

llvm-svn: 197717

llvm-svn: 197716

No longer leaking Argument objects after calling createArgument. However, since an OwningPtr cannot live in a std::vector yet, there are some manual deletions that have a FIXME attached to them. These will go away once C++11 support is allowed.

llvm-svn: 197715