first place.  The permutevar_* (note the *var*) intrinsics use ymm/mem.

llvm-svn: 146807

as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers.  That way this will always
be good.

llvm-svn: 146806

llvm-svn: 146805

avxintrin.h to take them into account.
Part of rdar://10595450

llvm-svn: 146804

This will be used by SimplifyCfg in a later commit.

llvm-svn: 146803

which have the dwarf DIE tag (DW_TAG_XXX enum) and TypeFlags for each type.

llvm-svn: 146802

asm parsing and testcase.

llvm-svn: 146801

llvm-svn: 146800

enhanced disassembler classify disassemblers by
target triple (as a string) rather than just by
the architecture component of the triple.  This
fixes a problem where different variants of the
Thumb instruction set were lumped into the same
hash bucket.

llvm-svn: 146799

llvm-svn: 146798

llvm-svn: 146797

Remove a non-gcc-compatible extension that would apply attributes on declarations without a declarator to structs.  Add a warning for ignored attributes.  Patch by Michael Han.

llvm-svn: 146796

llvm-svn: 146795

llvm-svn: 146794

Check if the input parameters are tainted (or point to tainted data) on
a checkPreStmt<CallExpr>. If the output should be tainted, record it in
the state. On post visit (checkPostStmt<CallExpr>), use the state to
make decisions (in addition to the existing logic). Use this logic for
atoi and fscanf.

llvm-svn: 146793

llvm-svn: 146792

intrinsics to use "I" (ICE) markings.  Fix avxintrin.h to take them into 
account.
Part of rdar://10595450

llvm-svn: 146791

I don't think this affects anything but verbose assembly.

llvm-svn: 146787

"half precision" floating-point with a first-class type.

This patch adds basic IR support (but not codegen support).

llvm-svn: 146786

pointer or a reference type - we actually just want the size of the
pointer then for that.

Fixes rdar://10335756

llvm-svn: 146785

llvm-svn: 146784

llvm-svn: 146783

llvm-svn: 146782

llvm-svn: 146781

llvm-svn: 146780

declaration for the type then go ahead and use that, it's still smaller
than creating an all new derived type.

Part of rdar://10335756 and others.

llvm-svn: 146779

classes.

Part of rdar://10520586 and a couple others.

llvm-svn: 146778

llvm-svn: 146777

valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider

Patch from Enrico Granata:

The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.

The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.

llvm-svn: 146768

The bad sorting caused a misaligned basic block when building 176.vpr in
ARM mode.

<rdar://problem/10594653>

llvm-svn: 146767

Fix an inconsistency in the syntactic form of InitListExpr in case of initialization that involves a ConstructorConversion

llvm-svn: 146766

#__include_macros) in the arguments of a function-style macro. Directives in the
arguments of such macros have undefined behaviour, and GCC does not correctly
support these cases. In some situations, this can lead to better diagnostics.

llvm-svn: 146765

llvm-svn: 146764

llvm-svn: 146763

This is equal to alignof(std::max_align_t) on the platform and equal to the
alignment provided by malloc. (Platform owners please double-check your
platform's value.)

llvm-svn: 146762

llvm-svn: 146761

llvm-svn: 146760

llvm-svn: 146759

take them into account.
rdar://10590282

llvm-svn: 146758

take them into account.
rdar://10576962

llvm-svn: 146757