llvm-svn: 183219

llvm-svn: 183218

llvm-svn: 183217

GCC complains about casting away const.

llvm-svn: 183216

Test commit for user vmedic, to verify commit access. One line of comment is added to MipsAsmParser.cpp.

llvm-svn: 183215

Fix ALIGNED misuse in asan_thread.cc (built on all platforms); also, add a comment to the ALIGNED macro describing the correct usage

llvm-svn: 183214

[llvm-symbolizer] Avoid calling slow getSymbolSize for Mach-O files. Assume that symbols with zero size are in fact large enough.

llvm-svn: 183213

llvm-svn: 183211

llvm-svn: 183210

The text of this diagnostic was unnecessarily specific to the current ARM
implementation of validateConstraintModifier, and it gave a potentially
confusing suggestion for fixing the problem. The ARM-specific issue is not
a big deal since that is the only target that currently does any checking of
asm operand modifiers, but until my change in 183172 it was still wrong for
output operands in the way that it referred to the value being truncated when
put into a register, since output operands are retrieved from the registers
instead of being put into them. The bigger problem is that its suggestion to
"use a modifier" is wrong and confusing in the case where a "q" modifier is
incorrectly used with an "r" constraint. In that case, the solution might
well be to remove the modifier or perhaps change the constraint. It's better
to just leave the diagnostic message more generic.

llvm-svn: 183209

llvm-svn: 183206

Specifically the following work was done:

1. If the operation was not implemented, I implemented it.

2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.

Also unittests have been added for all of the functions which did not
already have a unittest.

llvm-svn: 183179

Adding support for MSVC #pragma detect_mismatch functionality by emitting a FAILIFMISMATCH linker command into the object file.

llvm-svn: 183178

If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, just return the current PrivateStopInfo.

Also renamed a few more places where we were using StopReason in functions that were returning StopInfo's.

<rdar://problem/14042692>

llvm-svn: 183177

llvm-svn: 183176

llvm-svn: 183175

(4.58s vs 3.2s on an oldish Mac Tower). 

  The corresponding src is excerpted bellow. The lopp accounts for about 90% of execution time.
  --------------------
    cat -n test-suite/MultiSource/Benchmarks/Olden/em3d/make_graph.c
     90 
     91         for (k=0; k<j; k++)
     92           if (other_node == cur_node->to_nodes[k]) break;

  The defective layout is sketched bellow, where the two branches need to swap.
  ------------------------------------------------------------------------
      L:
         ...
      if (cond) goto out-of-loop
      goto L

  While this code sequence is defective, I don't understand why it incurs 1/3 of 
execution time. CPU-event-profiling indicates the poor laoyout dose not increase
in br-misprediction; it dosen't increase stall cycle at all, and it dosen't 
prevent the CPU detect the loop (i.e. Loop-Stream-Detector seems to be working fine
as well)... 

   The root cause of the problem is that the layout pass calls AnalyzeBranch() 
with basic-block which is not updated to reflect its current layout.

rdar://13966341

llvm-svn: 183174

Still missing cases for templates, but this is a step in the right
direction. Also omits suggestions that would be ambiguous (eg: void
func(int = 0); + void func(float = 0); func;)

llvm-svn: 183173

We're getting reports of this warning getting triggered in cases where it
is not adding any value. There is no asm operand modifier that you can use
to silence it, and there's really nothing wrong with having an LDRB, for
example, with a "char" output.

llvm-svn: 183172

llvm-svn: 183167

...but don't yet migrate over the existing plist tests. Some of these
would be trivial to migrate; others could use a bit of inspection first.
In any case, though, the new edge algorithm seems to have proven itself,
and we'd like more coverage (and more usage) of it going forwards.

llvm-svn: 183165

A.1 -> A -> B
becomes
A.1 -> B

This only applies if there's an edge from a subexpression to its parent
expression, and that is immediately followed by another edge from the
parent expression to a subsequent expression. Normally this is useful for
bringing the edges back to the left side of the code, but when the
subexpression is on a different line the backedge ends up looking strange,
and may even obscure code. In these cases, it's better to just continue
to the next top-level statement.

llvm-svn: 183164

Specifically, if the line is over 80 characters, or if the top-level
statement spans mulitple lines, we should preserve sub-expression edges
even if they form a simple cycle as described in the last commit, because
it's harder to infer what's going on than it is for shorter lines.

llvm-svn: 183163

Generating context arrows can result in quite a few arrows surrounding a
relatively simple expression, often containing only a single path note.

|
1 +--2---+
v/       v
auto m = new m // 3 (the path note)
|\       |
5 +--4---+
v

Note also that 5 and 1 are two ends of the "same" arrow, i.e. they go from
event to event. 3 is not an arrow but the path note itself.

Now, if we see a pair of edges like 2 and 4---where 4 is the reverse of 2
and there is optionally a single path note between them---we will
eliminate /both/ edges. Anything more complicated will be left as is
(more edges involved, an inlined call, etc).

The next commit will refine this to preserve the arrows in a larger
expression, so that we don't lose all context.

llvm-svn: 183162

llvm-svn: 183161

The old edge builder didn't have a notion of nested statement contexts,
so there was no special treatment of a logical operator inside an if
(or inside another logical operator). The new edge builder always tries
to establish the full context up to the top-level statement, so it's
important to know how much context has been established already rather
than just checking the innermost context.

This restores some of the old behavior for the old edge generation:
the context of a logical operator's non-controlling expression is the
subexpression in the old edge algorithm, but the entire operator
expression in the new algorithm.

llvm-svn: 183160

The current edge-generation algorithm sometimes creates edges from a
top-level statement A to a sub-expression B.1 that's not at the start of B.
This creates a "swoosh" effect where the arrow is drawn on top of the
text at the start of B. In these cases, the results are clearer if we see
an edge from A to B, then another one from B to B.1.

Admittedly, this does create a /lot/ of arrows, some of which merely hop
into a subexpression and then out again for a single note. The next commit
will eliminate these if the subexpression is simple enough.

This updates and reuses some of the infrastructure from the old edge-
generation algorithm to find the "enclosing statement" context for a
given expression. One change in particular marks the context of the
LHS or RHS of a logical binary operator (&&, ||) as the entire operator
expression, rather than the subexpression itself. This matches our behavior
for ?:, and allows us to handle nested context information.

<rdar://problem/13902816>

llvm-svn: 183159

Although we don't want to show a function entry edge for a top-level path,
having it makes optimizing edges a little more uniform.

This does not affect any edges now, but will affect context edge generation
(next commit).

llvm-svn: 183158

Neither the compiler nor the analyzer are doing anything with non-VarDecl
decls in the CFG, and having them there creates extra nodes in the
analyzer's path diagnostics. Simplify the CFG (and the path edges) by
simply leaving them out. We can always add interesting decls back in when
they become relevant.

Note that this only affects decls declared in a DeclStmt, and then only
those that appear within a function body.

llvm-svn: 183157

- adding workaround recommended by Greg (-fno-limit-debug-info clang flag)
- filed bug llvm.org/pr16214 against Clang

llvm-svn: 183156

llvm-svn: 183155

Getting PIDs on Windows is broken. Proper fix is simple but requires testing so
just disabling PID-based file names for now.

llvm-svn: 183154

- ConstantDataArray is not a valid MDNode operand
- encode function-name strings in metadata by wrapping in an MDString instead

- should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/

llvm-svn: 183153

PR16069 is an interesting case where an incoming value to a PHI is a
trap value while also being a 'ConstantExpr'.

We do not consider this case when performing the 'HoistThenElseCodeToIf'
optimization.

Instead, make our modifications more conservative if we detect that we
cannot transform the PHI to a select.

llvm-svn: 183152

llvm-svn: 183151

llvm-svn: 183150

This matches the behavior of MemberExpr and makes diagnostics such as
"reference to non-static member function must be called" more legible in
the case that the base & member are split over multiple lines (prior to
this change the diagnostic would point to the base, not the member -
making it very unclear in chained multi-line builder-style calls)

llvm-svn: 183149

Thanks to Sean Silva for noticing it!

llvm-svn: 183148

This was missing from r182908. I didn't noticed it at the time because the MCJIT tests were
disabled when building with cmake on ppc64 (which I fixed in r183143).

llvm-svn: 183147

llvm-svn: 183146