Make sys::ThreadLocal<> zero-initialized on non-thread builds (PR18205)

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.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197718 91177308-0d34-0410-b5e6-96231b3b80d8
Update the links to the SPARC information.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197719 91177308-0d34-0410-b5e6-96231b3b80d8
Changed the X86 assembler for intel syntax to work with directional labels.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197728 91177308-0d34-0410-b5e6-96231b3b80d8
Revert my change to the X86 assembler for intel syntax to work with
directional labels.  Because it doesn't work for windows :)


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197731 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure deterministic when printing ARM assembler constant pools

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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197735 91177308-0d34-0410-b5e6-96231b3b80d8
Change getStringRepresentation to skip defaults.

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197740 91177308-0d34-0410-b5e6-96231b3b80d8
Use $ORIGIN when setting rpath.

This matches what the configure build does.

Patch by Jan Vesely.

Fixes pr14189.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197743 91177308-0d34-0410-b5e6-96231b3b80d8
Un-revert: the buildbot failure in LLVM on lld-x86_64-win7 had me with
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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197744 91177308-0d34-0410-b5e6-96231b3b80d8
Update the ML test to expect the new string format of getStringRepresentation.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197750 91177308-0d34-0410-b5e6-96231b3b80d8
Fix documentation typos

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197757 91177308-0d34-0410-b5e6-96231b3b80d8
Makefile.ocaml: Tweak to use --system-libs.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197758 91177308-0d34-0410-b5e6-96231b3b80d8
move test back into the parent directory and add a REQUIRES: obj emission.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197759 91177308-0d34-0410-b5e6-96231b3b80d8
[x86] Rename In32BitMode predicate to Not64BitMode

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197768 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly apply the default pointer size


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197770 91177308-0d34-0410-b5e6-96231b3b80d8
When parsing data layout string looking for endianness, use the correct default


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197771 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the AnyPointerSize and AnyEndianness enumerators, which were left from
LLVM's early days.  Today LLVM IR is always target-specific.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197772 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for a CU to output a set of ranges for the CU. This is useful
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197776 91177308-0d34-0410-b5e6-96231b3b80d8
Makefile.unittest: cleanup may fail. Add '-' in the action.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197777 91177308-0d34-0410-b5e6-96231b3b80d8
Ranges in the .debug_range section need to have begin and end labels,
assert that this is so.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197780 91177308-0d34-0410-b5e6-96231b3b80d8
This test requires object emission.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197781 91177308-0d34-0410-b5e6-96231b3b80d8