llvm-svn: 272132

llvm-svn: 272131

llvm-svn: 272130

llvm-svn: 272129

[clang-tidy] misc-macro-parentheses - avoid adding parentheses in variable declarations

Fixes bugzilla issues 26273 and 27399

Reviewers: alexfh

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D20853

llvm-svn: 272128

isSwift is tested earlier and known to be false when we reach this code.

llvm-svn: 272127

As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.

llvm-svn: 272126

This could lead to column limit violations.

llvm-svn: 272125

.. and simplify it.

Before:
  void A::f()&& {}
  void f() && {}

After:
  void A::f() && {}
  void f() && {}

llvm-svn: 272124

Differential Revision: http://reviews.llvm.org/D21002

llvm-svn: 272123

llvm-svn: 272122

Only half of the intrinsics in this file is documented here. The patch for the o
ther half will be sent out later.

The doxygen comments are automatically generated based on Sony's intrinsics docu
ment.

I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.

llvm-svn: 272121

Previously this test performed check of binary data. Since
llvm-readobj currently able to dump all 3 types of version relative
sections, that can be used to make this test more transparent.
Patch do that.

Differential revision: http://reviews.llvm.org/D21024

llvm-svn: 272120

[AVX512] Reformat macro intrinsics, ensure arguments have proper typecasts, ensure result is typecasted back to the generic types.

llvm-svn: 272119

llvm-svn: 272118

llvm-svn: 272117

llvm-svn: 272116

Cleanup setup of subtarget features.

llvm-svn: 272091

[libFuzzer] add a test that is built w/o coverage instrumentation but has the coverage rt (it should now fail with a descriptive message)

llvm-svn: 272090

- lprofCurFilename was intended to have external visibility. This is
  pending further discussion.
- The raw version number doesn't need to be hidden: hiding it may make
  it easier to accidentally combine FE/IR profiles.

See the mailing list discussion on r272081.

llvm-svn: 272089

llvm-svn: 272088

IsPointedCString has problems with ValueObjects of type eTypeHostAddress.  We should
figure out the right thing to do in that case, but the test is silly here because we're
reading a type we've defined, so we know it is a const char *, and if the memory is good, 
we won't be able to read any characters, when we do ReadPointedString.

<rdar://problem/26612812>

llvm-svn: 272087

Long term we may want to give high cost at FPR to/from GPR copies.

llvm-svn: 272086

The generic implementation stated that all copies were free, which is
unlikely. Now, only the copies within the same register bank are free.
We assume they will get coalesced.

llvm-svn: 272085

The cost of a copy may be different based on how many bits we have to
copy around. E.g., a 8-bit copy may be different than a 32-bit copy.

llvm-svn: 272084

This will allow code reuse in the coming commits.

llvm-svn: 272083

The MachineMemOperand parser lacked the code to handle %stack.X
references (%fixed-stack.X was working).

llvm-svn: 272082

There are still a few external symbols visible from InstrProfData.inc.
The plan for dealing with those isn't as straightforward, so I'll try it
in a separate commit.

llvm-svn: 272081

Given the following C++:

```
void foo();
void foo() __attribute__((enable_if(false, "")));

bool bar() {
  auto P = foo;
  return P == foo;
}
```

We'll currently happily (and correctly) resolve `foo` to the `foo`
overload without `enable_if` when assigning to `P`. However, we'll
complain about an ambiguous overload on the `P == foo` line, because
`Sema::CheckPlaceholderExpr` doesn't recognize that there's only one
`foo` that could possibly work here.

This patch teaches `Sema::CheckPlaceholderExpr` how to properly deal
with such cases.

Grepping for other callers of things like
`Sema::ResolveAndFixSingleFunctionTemplateSpecialization`, it *looks*
like this is the last place that needed to be fixed up. If I'm wrong,
I'll see if there's something we can do that beats what amounts to
whack-a-mole with bugs.

llvm-svn: 272080

We attempted to use the UnaryTransformType's UnderlyingType instead of
it's BaseType.  This is not correct for dependent UnaryTransformType
because the have no underlying type.

This fixes PR28045.

llvm-svn: 272079

llvm-svn: 272078

We were previously failing to do this and as a result failing to drop
attached metadata.

Not sure if there's a good way to test this. An in-progress patch exposed this
problem by allocating a GlobalVariable at the same address as a previously
allocated GlobalVariable.

Differential Revision: http://reviews.llvm.org/D21109

llvm-svn: 272077

Summary:
When tcmalloc initializes before esan, esan's initialization ends up
calling back into tcmalloc due to the calloc done by dlsym.  This results
in a deadlock.  We avoid this by special-casing this single allocation.

Intercepting calloc also gives us the opportunity to act on its zeroing as
stores by the application.

Reviewers: aizatsky

Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka

Differential Revision: http://reviews.llvm.org/D21086

llvm-svn: 272076

In the reference code, the field name is `cHashBuckets`.

llvm-svn: 272075

llvm-svn: 272074

llvm-svn: 272073

This fixes linking problems on OSX.

Unfortunately it turns out we need to use an instance of the
``fuzzer::ExternalFunctions`` object in several places so this
commit also replaces all instances with a single global instance.

It also turns out initializing a global ``fuzzer::ExternalFunctions``
before main is entered (i.e. letting the object be initialised by the
global initializers) is not safe (on OSX the call to ``Printf()`` in the
CTOR crashes if it is called from a global initializer) so we instead
have a global ``fuzzer::ExternalFunctions*`` and initialize it inside
``FuzzerDriver()``.

Multiple unit tests depend also depend on the
``fuzzer::ExternalFunctions*`` global so a ``main()`` function has been
added that initializes it before running any tests.

Differential Revision: http://reviews.llvm.org/D20943

llvm-svn: 272072

Now that there are no cycles that cause leaks in the disassembler/instruction classes, we can get rid of the FIXME lines that were working around this issue.

<rdar://problem/26684190>

llvm-svn: 272071

[docs] fix the build by including ScudoHardenedAllocator into toc; mention SourceBasedCodeCoverage.html in libFuzzer docs

llvm-svn: 272070

Fix a memory leak in InstructionLLVMC where it held onto a strong reference to the DisassemblerLLVMC which in turn had a vector of InstructionSP causing the strong cycle. This is fixed now.

Rules are as follows for internal code using lldb::DisassemblerSP and lldb::InstructionSP:
1 - The disassembler needs to stay around as long as instructions do as the Instruction subclass now has a weak pointer to the disassembler
2 - The public API has been fixed so that if you get a SBInstruction, it will hold onto a strong reference to the disassembler in a new InstructionImpl class

This will keep code like like: 

inst = lldb.target.ReadInstructions(frame.GetPCAddress(), 1).GetInstructionAtIndex(0)
inst.GetMnemonic()

Working as expected (not the SBInstructionList() that was returned by SBTarget.ReadInstructions() is gone, but "inst" has a strong reference inside of it to the disassembler and the instruction.
                                                     
All code inside the LLDB shared library was verified to correctly hold onto the disassembler instance in all places.

<rdar://problem/24585496>

llvm-svn: 272069