* Display the strong/weak count in the summary
* Display the pointed object as a synthetic member
* Create synthetic children for weak/strong count

Differential revision: https://reviews.llvm.org/D25726

llvm-svn: 284828

While looking for guards use reverse iterator and scan up to rend() not to begin()

llvm-svn: 284827

Because we're just 'or-ing' these 2 variables later in the code, I
don't think there's a logical bug here, but of course the string with
"no size" is the one that should have the size suffix stripped off.

llvm-svn: 284826

Fixes Bug 28215. Lit tests updated.

Differential Revision: https://reviews.llvm.org/D25837

llvm-svn: 284825

As discussed in D24815, let's start the process of killing off the broken fast-math global
state housed in TargetOptions and eliminate the need for function-level fast-math attributes.

Here we enable two similar folds that are possible when we don't care about signed-zero:
fadd nsz x, 0 --> x
fsub nsz 0, x --> -x

Note that although the test cases include a 'sin' function call, I'm side-stepping the 
FMF-on-calls question (and lack of support in the DAG) for now. It's not needed for these
tests - isNegatibleForFree/GetNegatedExpression just look through a ISD::FSIN node.

Also, when we create an FNEG node and propagate the Flags of the FSUB to it, this doesn't
actually do anything today because Flags are silently dropped for any node that is not a
binary operator.

Differential Revision: https://reviews.llvm.org/D25297

llvm-svn: 284824

llvm-svn: 284823

llvm-svn: 284822

llvm-svn: 284821

    
When doing a relocatable link the .ARM.exidx sections with the
SHF_LINK_ORDER flag set need to set the sh_link field to the executable
section they describe. We find the appropriate OutputSection by
following the sh_link field of the .ARM.exidx InputSections.
    
The getOutputSectionName() function rules make sure that when there are
multiple .ARM.exidx InputSections in an OutputSection they all have the
same sh_link field.

Differential revision: https://reviews.llvm.org/D25825

llvm-svn: 284820

This tests that lldb handles the situation when a single instruction triggers
multiple watchpoint hits. It currently fails on arm due to what appears to be a
lldb-server bug (pr30758).

llvm-svn: 284819

When we have a loop with a known upper bound on the number of iterations, and
furthermore know that either the number of iterations will be either exactly
that upper bound or zero, then we can fully unroll up to that upper bound
keeping only the first loop test to check for the zero iteration case.

Most of the work here is in plumbing this 'max-or-zero' information from the
part of scalar evolution where it's detected through to loop unrolling. I've
also gone for the safe default of 'false' everywhere but howManyLessThans which
could probably be improved.

Differential Revision: https://reviews.llvm.org/D25682

llvm-svn: 284818

Revert "Fix a race condition between "ephemeral watchpoint disable/enable" and continue in commands."

This reverts commit r284795, as it breaks watchpoint handling on arm (and
presumable all architectures that report watchpoint hits without executing the
tripping instruction).

There seems to be something fundamentally wrong with this patch: it uses
process_sp->AddPreResumeAction to re-enable the watchpoint, but the whole point
of the step-over-watchpoint logic (which AFAIK is the only user of this class) is
to disable the watchpoint *after* we resume to do the single step.

I have no idea how to fix this except by reverting the offending patch.

llvm-svn: 284817

[X86][AVX] Add 32-bit target tests for vector lzcnt/tzcnt to demonstrate missed folding opportunities

llvm-svn: 284816

This picked up a builtin header if it happened to be available.

llvm-svn: 284815

Summary:
The spill size was incorrectly set to 196 bits,
which isn't a multiple of 8. This problem was detected when
experimenting with asserts that the spill size should be a
multiple of the byte size.

New corrected value for the spill size is set to 192 bits.

Note that tablegen (RegisterInfoEmitter) will divide the
size set in the RegisterClass definition by 8. So this
change should not have any impact on the tablegen output
(trunc(192/8) == trunc(196/8) == 24 bytes).

Reviewers: t.p.northover

Subscribers: llvm-commits, aemerson, rengolin

Differential Revision: https://reviews.llvm.org/D25818

llvm-svn: 284814

The change to MachineSink shuffles code around, disable it.

llvm-svn: 284813

On i386 alignof(double) = 8 is not the same as alignof(struct { double
}) = 4. This used to be not an issue because the old implementation
always measured alignment inside of structs. Wrap a dummy struct around
the test to avoid this issue.

llvm-svn: 284812

This reverts commit r284800, as it failed all ARM/AArch64 bots.

llvm-svn: 284811

rL284708 introduces a link error when building with BUILD_SHARED_LIBS:

undefined reference to `llvm::DWARFContext::parseCompileUnits()'
undefined reference to `llvm::DWARFContextInMemory::DWARFContextInMemory(
                            llvm::object::ObjectFile const&,
                            llvm::LoadedObjectInfo const*)'
The functions are available in libDebugInfoDWARF, from llvm.

Patch by Visoiu Mistrih Francis

Differential revision: https://reviews.llvm.org/D25843

llvm-svn: 284810

Some MIPS relocations used to access GOT entries are able to manipulate
16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle
32-bit indexes. 16-bit relocations are generated by default. The 32-bit
relocations are generated by -mxgot flag passed to compiler. Usually
these relocation are not mixed in the same code but files like crt*.o
contain 16-bit relocations so even if all "user's" code compiled with
-mxgot flag a few 16-bit relocations might come to the linking phase.

Now LLD does not differentiate local GOT entries accessed via a 16-bit
and 32-bit indexes. That might lead to relocation's overflow if 16-bit
entries are allocated to far from the beginning of the GOT.

The patch introduces new "part" of MIPS GOT dedicated to the local GOT
entries accessed by 32-bit relocations. That allows to put local GOT
entries accessed via a 16-bit index first and escape relocation's overflow.

Differential revision: https://reviews.llvm.org/D25833

llvm-svn: 284809

Commuting will be added in a future commit.

llvm-svn: 284808

Summary:
Previously, automatic semicolon insertion would add an unwrapped line
when a template string contained a line break.

    var x = `foo${
        bar}`;

Would be formatted with `bar...` on a separate line and no indent.

Reviewers: djasper

Subscribers: cfe-commits, klimek

Differential Revision: https://reviews.llvm.org/D25675

llvm-svn: 284807

llvm-svn: 284806

llvm-svn: 284805

llvm-svn: 284804

In-memory ELF object files created here are consumed immediately,
so as long as the generated files are syntactically correct, we don't
care about the details.

llvm-svn: 284803

we don't collapse that down to a single entry if it's not a redeclaration.
Instead, set the Redeclaration bit on the Declarator to indicate whether a
function is a redeclaration (which may not have been linked into the
redeclaration chain if it's a dependent context friend).

Fixes a rejects-valid; see testcase.

llvm-svn: 284802

These modules are necessary on Darwin to allow modules with
'no_undeclared_includes' (introduced in clang r284797) to work properly
while using libc++ headers.

Patch extracted from a suggested module.modulemap from Richard Smith!

llvm-svn: 284801

This has two significant effects:

1) Direct relational comparisons between null pointer constants (0 and nullopt)
   and pointers are now ill-formed. This was always the case for C, and it
   appears that C++ only ever permitted by accident. For instance, cases like
     nullptr < &a
   are now rejected.

2) Comparisons and conditional operators between differently-cv-qualified
   pointer types now work, and produce a composite type that both source
   pointer types can convert to (when possible). For instance, comparison
   between 'int **' and 'const int **' is now valid, and uses an intermediate
   type of 'const int *const *'.

Clang previously supported #2 as an extension.

We do not accept the cases in #1 as an extension. I've tested a fair amount of
code to check that this doesn't break it, but if it turns out that someone is
relying on this, we can easily add it back as an extension.

llvm-svn: 284800

This can happen if you debug an iOS corefile on
a mac, where PlatformPOSIX::GetHostname ends up
not providing a hostname because we're working 
with a platform of remote-ios.

llvm-svn: 284799

Recent versions of ld64 run a deduplicate pass, which is on by default.
Disable the pass by using -no_deduplicate in certain condition and
enhance total compile time.

rdar://problem/25455336

llvm-svn: 284798

The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are
accepted.

The main motivation behind this is to prevent dep cycles between system
libraries (such as darwin) and libc++.

Patch by Richard Smith!

llvm-svn: 284797

There's no agreement about this patch. I personally find the
PRE machinery of the current GVN hard enough to reason about
that I'm not sure I'll try to land this again, instead of working
on the rewrite).

llvm-svn: 284796

Also, watchpoint commands, like breakpoint commands, need to run in async mode.

This was causing intermittent failures in TestWatchpointCommandPython.py, which is now solid.

llvm-svn: 284795

llvm-svn: 284794

Tests fall into one of the following categories:

- The requirement was unnecessary

- Additional quoting was required for backslashes in paths (see "sed -e
  's/\\/\\\\/g'") in the sanitizer tests.

- OpenMP used 'REQUIRES: shell' as a proxy for the test failing on
  Windows. Those tests fail there reliably, so use XFAIL instead.

I tried not to remove shell requirements that were added to suppress
flaky test failures, but if I screwed up, we can add it back as needed.

llvm-svn: 284793

llvm-svn: 284792

by grubbing the break list output.  If you pass a number of locations into
the run_break_* functions, they will check that this is right for you.

llvm-svn: 284791

llvm-svn: 284790

rL284780 fixed the PREL31 relocation and added a test for it. Being
the first such test for ARM relocations, it exposed incorrect endianness
assumptions (causing buildbot failures on big-endian hosts). Fix that by
using the same helpers used for the x86 case.

llvm-svn: 284789