Also, rework the signed types test to check for signed or char type in the output as char is signed by default.

llvm-svn: 187533

passing a retainable object arg to a CF audited function
expecting a CF object type. Issue a normal type mismatch
diagnostic. This is wip // rdar://14569171

llvm-svn: 187532

llvm-svn: 187531

While the .td entry is nice and all, it takes a pretty gross hack in
ARMAsmParser::ParseInstruction() because of handling of other "subs"
instructions to get it to match.  Ran it by Jim Grosbach and he said it was
about what he expected to make this work given the existing code.

rdar://14214063

llvm-svn: 187530

llvm-svn: 187529

This change unifies the logic for template instantiation of methods and
functions declared with typedefs.

It ensures that SubstFunctionType() always fills the Params out param
with non-null ParmVarDecls or returns null.

Reviewers: rsmith

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

llvm-svn: 187528

This adds a few more clang-cl options. It also exposes two core clang
options to the clang-cl mode: we need to be able to claim --driver_mode
so it doesn't show up as unused in cl mode, and we need -### for tests.

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

llvm-svn: 187527

This reverts commit 98ce62780ea7185ba710868bf83c8077e8d7f6d6.

llvm-svn: 187526

This reverts commit 2ca1e4a39c7e0d7a00e66ff5437c6d7ace2404a0.

llvm-svn: 187525

This reverts commit 3f1de26cb5cc0543a6a1d71259a7a39d97139051.

llvm-svn: 187524

Fix lock hierarchy violation in Process (lock ordering of ThreadList mutex and StackFrameList mutex)
- this fix ensures the ThreadList mutex is always locked before the StackFrameList mutex

Situation where deadlock could occur (without this fix):
Thread 1 is in Process::WillResume and locks the ThreadList mutex (on entry), and subsequently calls StackFrameList::Clear() which locks the StackFrameList mutex.
Meanwhile, thread 2 is in Process::RunThreadPlan and calls Thread::SetSelectedFrame() (which locks the StackFrameList mutex) before calling GetSelectedThread (which attempts to lock the ThreadList mutex)

In my testing on both Linux and Mac OS X, I was unable to reproduce any hangs with this patch applied.

llvm-svn: 187522

llvm-svn: 187521

Patch from Andy Kaylor.

llvm-svn: 187520

TODO: Improve coverage of SBTypeMember and of 'target module dump'.
llvm-svn: 187519

llvm-svn: 187518

llvm-svn: 187517

If we merge vector when a vector is used, it will generate an artificial
antidependency that can prevent 2 tex/vtx instructions to use the same
clause and thus generate extra clauses that reduce performance.

There is no test case as such situation is really hard to predict.

llvm-svn: 187516

llvm-svn: 187515

llvm-svn: 187514

There are a lot of restrictions on instruction groups that contain
LDS instructions, so for now we will be conservative and not packetize
anything else with them.

llvm-svn: 187513

llvm-svn: 187512

llvm-svn: 187511

We were using two instructions for similar purpose : break and
predicated break. Only predicated_break was emitted and it was
lowered at R600ControlFlowFinalizer to JUMP;CF_BREAK;POP.
This commit simplify the situation by making AMDILCFGStructurizer
emit IF_PREDICATE;BREAK;ENDIF; instead of predicated_break (which
is now removed).

There is no functionality change.

llvm-svn: 187510

to avoid future false positives. // rdar://14569171

llvm-svn: 187509

for parameters passed to CF audited functions
to be used for better diagnostics. Current set but
unused. // rdar://14569171

llvm-svn: 187508

llvm-svn: 187507

llvm-svn: 187506

llvm-svn: 187505

changing '->' to '.' when there is no operator-> defined for a class.

llvm-svn: 187504

out of ImpCastExprToType and to the caller site
as appropriate. This is in prep. to do more work for
// rdar://14569171 

llvm-svn: 187503

llvm-svn: 187502

Also update comment in const variables test to reflect ICC status.

llvm-svn: 187501

Set an extra debug flag when testing with ICC so that it generates the correct debug info for inlined tests.

llvm-svn: 187500

provide more detail on compiler compatibility, and to illustrate that this is
an issue with expression evaluation.

- Note that clang doesn't emit DW_TAG_const_type, which might be okay if there's
no such thing as a non-const rvalue reference.  How about foo(make_int())?

llvm-svn: 187499

Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187498

The loop optimizers were assuming that scales > 1 were OK.  I think this
is actually a bug in TargetLoweringBase::isLegalAddressingMode(),
since it seems to be trying to reject anything that isn't r+i or r+r,
but it has no default case for scales other than 0, 1 or 2.  Implementing
the hook for z means that z can no longer test any change there though.

llvm-svn: 187497

Extend r187495 to conditional loads.  I split this out because the
easiest way seemed to be to force a particular operand order in
SystemZISelDAGToDAG.cpp.

llvm-svn: 187496

System z branches have a mask to select which of the 4 CC values should
cause the branch to be taken.  We can invert a branch by inverting the mask.
However, not all instructions can produce all 4 CC values, so inverting
the branch like this can lead to some oddities.  For example, integer
comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater).
If an integer EQ is reversed to NE before instruction selection,
the branch will test for 1 or 2.  If instead the branch is reversed
after instruction selection (by inverting the mask), it will test for
1, 2 or 3.  Both are correct, but the second isn't really canonical.
This patch therefore keeps track of which CC values are possible
and uses this when inverting a mask.

Although this is mostly cosmestic, it fixes undefined behavior
for the CIJNLH in branch-08.ll.  Another fix would have been
to mask out bit 0 when generating the fused compare and branch,
but the point of this patch is that we shouldn't need to do that
in the first place.

The patch also makes it easier to reuse CC results from other instructions.

llvm-svn: 187495

r187116 moved compare-and-branch generation from the instruction-selection
pass to the peephole optimizer (via optimizeCompare).  It turns out that even
this is a bit too early.  Fused compare-and-branch instructions don't
interact well with predication, where a CC result is needed.  They also
make it harder to reuse the CC side-effects of earlier instructions
(not yet implemented, but the subject of a later patch).

Another problem was that the AnalyzeBranch family of routines weren't
handling compares and branches, so we weren't able to reverse the fused
form in cases where we would reverse a separate branch.  This could have
been fixed by extending AnalyzeBranch, but given the other problems,
I've instead moved the fusing to the long-branch pass, which is also
responsible for the opposite transformation: splitting out-of-range
compares and branches into separate compares and long branches.

I've added a test for the AnalyzeBranch problem.  A test for the
predication problem is included in the next patch, which fixes a bug
in the choice of CC mask.

llvm-svn: 187494

llvm-svn: 187493