If no targets are registered, LLVMGetFirstTarget currently fails with
an assertion. This patch makes it return NULL instead, similarly to
how LLVMGetNextTarget would.

Patch by Peter Zotov

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

llvm-svn: 192878

llvm-svn: 192877

llvm-svn: 192876

llvm-svn: 192875

llvm-svn: 192874

llvm-svn: 192873

update docs for no_sanitize_thread attribute and blacklist

llvm-svn: 192872

If a function has no_sanitize_thread attribute,
do not instrument memory accesses in it.

llvm-svn: 192871

llvm-svn: 192870

llvm-svn: 192869

__attribute__ (( unavailable )) is for Apple specific builds.  Create a macro
to conditionalise the usage of the macro.  This is to aid in porting the
unwinder to other platforms.

llvm-svn: 192868

to GCC when asked to compile a fortran input.

This fixes a regression with essentially every Fortran compile since we
started rejecting unknown flags. Also moves a mis-classified gfortran
flag into the nicely documented set.

llvm-svn: 192867

Consider the following:

typedef unsigned short ushort4U __attribute__((ext_vector_type(4),
aligned(2)));
typedef unsigned short ushort4 __attribute__((ext_vector_type(4)));
typedef unsigned short ushort8 __attribute__((ext_vector_type(8)));
typedef int int4 __attribute__((ext_vector_type(4)));

int4 __bbase_cvt_int(ushort4 v) {
  ushort8 a;
  a.lo = v;
  return _mm_cvtepu16_epi32(a);
}

This generates the, not unreasonable, IR:
define <4 x i32> @foo0(double %v.coerce) nounwind ssp {
  %tmp = bitcast double %v.coerce to <4 x i16>
  %tmp1 = shufflevector <4 x i16> %tmp, <4 x i16> undef, <8 x i32> <i32
  %0, i32 1, i32 2, i32 3, i32 undef, i32 undef, i32 undef, i32 undef>
  %tmp2 = tail call <4 x i32> @llvm.x86.sse41.pmovzxwd(<8 x i16> %tmp1)
  ret <4 x i32> %tmp2
}

The problem is when type legalization gets hold of the v4i16. It
legalizes that by spilling to the stack, then doing a zero-extending
load. Things go even more silly from there, ending up with something
like:
_foo0:
  movsd %xmm0, -8(%rsp)       <== Spill to the stack.
  movq  -8(%rsp), %xmm0       <== Reload it right back out.
  pmovzxwd  %xmm0, %xmm1      <== Here's what we actually asked for.
  pblendw $1, %xmm1, %xmm0    <== We don't need this at all
  pmovzxwd  %xmm0, %xmm0      <== We already did this
  ret

The v8i8 to v8i16 zext intrinsic gives even worse results, with two
table lookups via pshufb instructions(!!).

To avoid all that, we can move the bitcasting until after we've formed
the wider (legal) vector type. Then our normal codegen flows along
nicely and we get the expected:
_foo0:
  pmovzxwd  %xmm0, %xmm0
  ret

rdar://15245794

llvm-svn: 192866

like C++ should be the fully qualified names for the type.

Add a routine that does a language specific context walk to build
up the qualified name and use it when we add types/names to the
tables. Expand the gnu pubnames testcase as it's the most complex
to make sure that qualified types are also being added.

llvm-svn: 192865

I expose the API with some caveats:

- The C++ API involves a traditional void* opaque pointer for the fatal 
error callback.  The C API doesn’t do this.  I don’t think that the void* 
opaque pointer makes any sense since this is a global callback - there will 
only be one of them.  So if you need to pass some data to your callback, 
just put it in a global variable.

- The bindings will ignore the gen_crash_diag boolean.  I ignore it because 
(1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I 
couldn’t imagine any use for it.  I made the gut call that it probably 
wasn’t important enough to expose through the C API.

llvm-svn: 192864

No functionality changes.

llvm-svn: 192863

function, not the context of the context.

llvm-svn: 192862

if they're a declaration, otherwise they're owned by the compile
unit.

llvm-svn: 192861

Summary:
These are deprecated in VS 2012 according to MSDN.  They don't actually
compile down to any code.  They prevent the compiler from reordering
memory accesses across the barrier, which is what a memory-clobbering
volatile asm does.

Reviewers: echristo

CC: cfe-commits

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

llvm-svn: 192860

The reason this got reverted was that the @feat.00 symbol which was emitted
for every TU became quoted, and on cygwin/mingw we use the gas assembler which
couldn't handle the quotes.

This commit fixes the problem by only emitting @feat.00 for win32, where we use
clang -cc1as to assemble. gas would just drop this symbol anyway, so there is no
loss there.

With @feat.00 gone, there shouldn't be quoted symbols showing up on cygwin since
it uses the Itanium ABI, which doesn't put these funny characters in symbols.

> Because of win32 mangling, we produce symbol and section names with
> funny characters in them, most notably @ characters.
>
> MC would choke on trying to parse its own assembly output. This patch addresses
> that by:
>
> - Making @ trigger quoting of symbol names
> - Also quote section names in the same way
> - Just parse section names like other identifiers (to allow for quotes)
> - Don't assume @ signifies a symbol variant if it is in a string.

llvm-svn: 192859

- Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication
- Finished up the target definition python setting stuff.
- Added a new "slice" key/value pair that can specify that a register is part of another register:
    { 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' },
- Added a new "composite" key/value pair that can specify that a register is made up of two or more registers:
    { 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] },
- Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers:
    { 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']},
    
This now completes the feature that allows a GDB remote target to completely describe itself.

llvm-svn: 192858

llvm-svn: 192857

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

when inferring property from setter/getter
methods. // rdar://15200949

llvm-svn: 192853

The C API currently allows to dump values (LLVMDumpValue), but a similar method for types was not exported.

Patch by Peter Zotov

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

llvm-svn: 192852

everything else in the class.

llvm-svn: 192851

llvm-svn: 192850

The test should be expanded upon for more powerpc checking.

llvm-svn: 192849

The referenced script no longer seems to exist.

llvm-svn: 192848

llvm-svn: 192847

declaration.

llvm-svn: 192846

llvm-svn: 192845

llvm-svn: 192844

llvm-svn: 192843

llvm-svn: 192842

inferred properties when type is scalar and
assumed to be 'assign. // rdar://15231241

llvm-svn: 192841

llvm-svn: 192840

Preprocessor support is still needed.

llvm-svn: 192839