On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping
and retrying should help us get more stable results.

llvm-svn: 274763

remote targets need a bit more time to get their act together

llvm-svn: 274762

Summary:
A regression showed up in node.js when handling conditional calls.
Fix the regression by recognizing external symbols as a possible
operand type in CallJG.

Reviewers: koriakin

Subscribers: llvm-commits

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

llvm-svn: 274761

llvm-svn: 274760

This patch introduces basic Vim integration for clang-rename tool.

For setup reference see clang-rename/tool/clang-rename.py

Patch by Kirill Bobyrev!

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

llvm-svn: 274759

moved the optimise for size check inside function optimizeFPuts.

llvm-svn: 274758

llvm-svn: 274757

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

llvm-svn: 274756

llvm-svn: 274755

Fixes pr28452.

llvm-svn: 274754

because fwrite requires more arguments and thus extra MOVs are required.

llvm-svn: 274753

With this there are no unsupported tests on linux in test/ELF :-)

llvm-svn: 274752

Currently, to be able to process a source file including e.g. stddef.h with
clang-tidy, one has to build both clang-tidy and the clang-headers target.
Since stddef.h is needed for virtually any source file, let clang-tidy depend
on clang-headers, so that it Just Works after it has been built.

http://reviews.llvm.org/D22046

llvm-svn: 274751

Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
 1) The first part changes the unwinding strategy, earlier the
    default unwinder was used to get 2 more stack frames and if it
    failed a fallback unwinder was used. Now we try to obtain as many
    frames (max 10) as we can get from default unwinder and also
    fallback unwinder and use the one that gives more number of frames.
    
 2) Normally unwindplans are assosciated with functions and the
    row to be used is obtained from the offset (obtained from the low_pc
    of the function symbol). Sometimes it may occur that the unwindplan
    is assosciated to the complete Elf section in which case the offset
    calculation would be wrong as the debugger uses the same offset originally
    obtained from the function symbol. Hence this offset is recalculated.

Reviewers: tberghammer, lldb-commits, labath, jasonmolenda

Subscribers: jingham

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

llvm-svn: 274750

This patch adds synchronization between the creation of the GCD data object and destructor’s execution. It’s far from perfect, because ideally we’d want to synchronize the destruction of the last reference (via dispatch_release) and the destructor’s execution, but intercepting objc_release is problematic.

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

llvm-svn: 274749

This time without causing a 'all enums handled' warning on other compilers.

llvm-svn: 274748

llvm-svn: 274746

OpenMP relies on some helper expressions generated during semantic
analysis. But they are required only for codegen and not required in
dependent contexts. Patch removes generation of some of helper
expressions.

llvm-svn: 274745

These registers are only available on a limited set of ARM targets (those
based on XScale). Other targets should not have to pay the cost of these.

This patch shaves off about ~300 bytes of stack usage and ~1KB of code-size.

Differential revision: http://reviews.llvm.org/D21991
Reviewers: bcraig, compnerd

Change-Id: I2d7a1911a193bd70b123e78747e1a7d1482463c7
llvm-svn: 274744

llvm-svn: 274743

This is a follow-up for r273544.

The end goal is to get rid of the isSwift / isCortexXY / isWhatever methods.

This commit also removes a command line flag that isn't used in any of the tests:
check-vmlx-hazards. It can be replaced easily with the mattr mechanism, since
this is now a subtarget feature.

There is still some work left regarding FeatureExpandMLx. In the past MLx
expansion was enabled for subtargets with hasVFP2(), until r129775 [1] switched
from that to isCortexA9, without too much justification.

In spite of that, the code performing MLx expansion still contains calls to
isSwift/isLikeA9, although the results of those are pretty clear given that
we're only enabling it for the A9.

We should try to enable it for all targets that have FeatureHasVMLxHazards, as
it seems to be closely related to that behaviour, and if that is possible try to
clean up the MLx expansion pass from all calls to isWhatever. This will require
some performance testing, so it will be done in another patch.

[1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110418/119725.html

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

llvm-svn: 274742

Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565

The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo &region_info).

Reviewers: clayborg

Subscribers: labath, lldb-commits

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

llvm-svn: 274741

friend definitions.

Based on the experiments Sean Silva and Reid did, this seems the safest
course of action and also will work around a questionable warning
provided by GCC6 on the old form of the code. Thanks for Davide pointing
out the issue and other suggesting ways to fix.

llvm-svn: 274740

Previously we had incorrect logic here. Imagine we would have the next script:

LIBSAMPLE_1.0
{
  global:
   a_2;
 local:
  *;
};

LIBSAMPLE_2.0
{
  global:
   a*;
};
According to previous logic it would assign version 1 to a_2 and then
would try to reassign it to version 2 because of applying wildcard a*.
And show a warning about that.

Generally Ian Lance Tailor wrote about next rules that should be applied:
(http://www.airs.com/blog/archives/300)

Here are the current rules for gold:

"If there is an exact match for the mangled name, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error.
Otherwise, we look for an extern C++ or an extern Java exact match. If we find an exact match, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error.
Otherwise, we look through the wildcard patterns, ignoring “*” patterns. We look through the version tags in reverse order. For each version tag, we look through the global patterns and then the local patterns. We use the first match we find (i.e., the last matching version tag in the file).
Otherwise, we use the “*” pattern if there is one. We give a warning if there are multiple “*” patterns."

Patch makes wildcard matching to be in revered order and to follow after the regular naming matching.

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

llvm-svn: 274739

We were inappropriately using 32-bit types to account for quantities
that can be far larger.

Fixed in PR28443.

llvm-svn: 274737

[AVX512] Zero extend the result of vpcmpeq/vpcmpgt and similar intrinsics in the autoupgrade code. This currently results in worse codegen but is needed for correctness.

llvm-svn: 274736

Vectorizing GEP was incorrect and broke SSA in some cases.
 
The patch fixes PR27997 https://llvm.org/bugs/show_bug.cgi?id=27997.

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

llvm-svn: 274735

llvm-svn: 274734

Optimize the bitfield types to conserve space for the MSVC ABI.

llvm-svn: 274733

ArrayRef is a little better than passing around a pointer/length
pair.

No functional change is intended.

llvm-svn: 274732

Summary: This patch is adding support to recognize more complex redundant expressions.

Reviewers: alexfh

Subscribers: aaron.ballman, cfe-commits, chrisha

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

llvm-svn: 274731

We have "REQUIRES: zlib" in our test, but zlib was not defined,
so the test did not run on any platform.

llvm-svn: 274730

Previously, ch_size was read in host byte order, so if a host and
a target are different in byte order, we would produce a corrupted
output.

llvm-svn: 274729

llvm-svn: 274728

Summary:
Handles binaries built with -esan-aux-field-info=false and print less
information.

Updates test struct-simple.cpp.

Reviewers: aizatsky

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

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

llvm-svn: 274727

Summary:
Adds option -esan-aux-field-info to control generating binary with
auxiliary struct field information.

Extracts code for creating auxiliary information from
createCacheFragInfoGV into createCacheFragAuxGV.

Adds test struct_field_small.ll for -esan-aux-field-info test.

Reviewers: aizatsky

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

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

llvm-svn: 274726

os name and version # from the mach-o binary as it scans the
header/load commands from memory and sends the details back
in the jGetLoadedDynamicLibrariesInfos response.  lldb isn't
using these fields yet but I have a suspicion I'm going to 
need them soon.

<rdar://problem/25251243> 

llvm-svn: 274725

llvm-svn: 274724

warning() depends on Config->FatalWarnings, so we don't want to call
that function before we initialize that member.

llvm-svn: 274723

This check is not only unnecessary, it can produce the wrong result. If we
are linking a single module and it has an exported linkonce symbol, we need
to promote to weak in order to avoid PR19901-style problems.

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

llvm-svn: 274722