llvm-svn: 183243

[libclang] When annotating tokens, don't override a property annotation with a getter/setter method annotation.

rdar://13764549

llvm-svn: 183242

IndVarSimplify is willing to move divide instructions outside of their
loop bodies if they are invariant of the loop.  However, it may not be
safe to expand them if we do not know if they can trap.

Instead, check to see if it is not safe to expand the instruction and
skip the expansion.

This fixes PR16041.

Testcase by Rafael Ávila de Espíndola.

llvm-svn: 183239

The ARM backend did not expect LDRBi12 to hold a constant pool operand.
Allow for LLVM to deal with the instruction similar to how it deals with
LDRi12.

This fixes PR16215.

llvm-svn: 183238

Consider the case where a SwitchStmt satisfied isAllEnumCasesCovered()
as well as having no cases at all (i.e. the enum it covers has no
enumerators).

In this case, we should add a successor to repair the CFG.

This fixes PR16212.

llvm-svn: 183237

Summary:
There's Lexer::getBufferStart(), and we need getBufferEnd() to access
the whole input buffer in clang::format::reformat. We don't want to
rely on the fact that the Lexer::BufferEnd always points to '\0', as there can
be embedded '\0's as well.

Reviewers: jordan_rose

Reviewed By: jordan_rose

CC: cfe-commits

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

llvm-svn: 183236

arrays of empty structs. // rdar://14053082
(also pr13062).

llvm-svn: 183234

- link libexecinfo (as libc is missing backtrace())
- enable FreeBSD-specific plugins

Patch by Ed Maste!

llvm-svn: 183233

Summary:
 Parser/Registry argument enhancements.
  - 2 argument support.
  - unsigned values support.

Reviewers: klimek

CC: cfe-commits, revane

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

llvm-svn: 183231

Specifying the load address for Darwin i386 dylibs was a performance
optimization for dyld that is not relevant for x86_64 or arm. We can just
remove this now.

llvm-svn: 183230

llvm-svn: 183229

llvm-svn: 183228

This enables changing clang-check to get extra arguments.

Patch by Pavel Labath.

llvm-svn: 183227

The problem this time seems to be a thinko. We were assuming that in the CFG

A
| \
|  B
| /
C

speculating the basic block B would cause only the phi value for the B->C edge
to be speculated. That is not true, the phi's are semantically in the edges, so
if the A->B->C path is taken, any code needed for A->C is not executed and we
have to consider it too when deciding to speculate B.

llvm-svn: 183226

llvm-svn: 183225

llvm-svn: 183224

llvm-svn: 183223

Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.

llvm-svn: 183222

llvm-svn: 183221

Summary:
With this change, the user may safely call __asan_get_ownership()
from malloc/free hooks and assume it would return "true". If there is a
realloc/free race, free hook might be called twice, but I think it's acceptable,
as it's a data race and would later be reported anyway.

This change also fixes a bug when failing realloc incorrectly marked the
original memory as "quarantinned".

Reviewers: timurrrr, kcc, samsonov

Reviewed By: samsonov

CC: llvm-commits

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

llvm-svn: 183220

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