llvm-svn: 232387

There are no opcodes for this. This also adds a test case.

v2: make test more robust

Patch by: Grigori Goronzy

llvm-svn: 232386

llvm-svn: 232385

Fix a problem when calling throw_with_nested with a class marked 'final'. Thanks to STL @ Microsoft for the bug report.

llvm-svn: 232384

We already have a definition for the Czech locale name in
platform_support.h. Use this one instead.

While there, respect the common format of the tests. For most other
tests it's the case that test_iterators.h is placed right underneath the
other #includes (without an empty line). platform_support.h is included
after an empty line.

llvm-svn: 232383

Fix justify error for small structures bigger than 32 bits in fixed
arguments for MIPS64 big endian. There was a problem when small structures
are passed as fixed arguments. The structures that are bigger than 32 bits
but smaller than 64 bits were not left justified properly on MIPS64 big
endian. This is fixed by shifting the value to make it left justified when
appropriate.

Patch by Aleksandar Beserminji.

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

llvm-svn: 232382

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

llvm-svn: 232381

I think the issue that caused the random failure has been fixed. So I am enabling the tests again on Linux.
There are still some tests that are skipped on Linux due to different output. Those will be handled separately.

Tested with dotest.py and with "make check-lldb" and there was no MI related failure.

llvm-svn: 232380

According to POSIX, *abs() and *div() are allowed to be macros (in
addition to being functions). Make sure we undefine these, so that
std::*abs() and std::*div() work as expected.

llvm-svn: 232379

llvm-svn: 232378

Reviewed at http://reviews.llvm.org/D8321

llvm-svn: 232377

2007-12-17-InvokeAsm.ll fails on the buildbot but not on my own system. Will investigate.

llvm-svn: 232376

llvm-svn: 232375

Summary:
But still handle them the same way since I don't know how they differ on
this target.

No functional change intended.

Reviewers: kparzysz, adasgupt

Reviewed By: kparzysz, adasgupt

Subscribers: colinl, llvm-commits

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

llvm-svn: 232374

Summary:
This is instead of doing this in target independent code and is the last
non-functional change before targets begin to distinguish between
different memory constraints when selecting code for the ISD::INLINEASM
node.

Next, each target will individually move away from the idea that all
memory constraints behave like 'm'.

Subscribers: jholewinski, llvm-commits

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

llvm-svn: 232373

Following 3 changes were made.
1. Test was assuming that function name will have () in the end. I dont know why lldb is generating function name like this but it looks like a bug. For this test, I have removed it.
2. Step instruction test was assuming that function call will not be the first instruction in the range of the line. This assumption failed with gcc. So I had fixed this.
3. Some minor adjustments with the line number.

Test with bot gcc and clang and all tests pass.

This test is still very fragile. We should be removing hardcoded line number.

llvm-svn: 232372

Summary: Make the code more readable by outlining NOP creation.

Reviewers: dsanders

Reviewed By: dsanders

Subscribers: llvm-commits

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

llvm-svn: 232371

Not checking for this flags caused lldb-mi to issue stop notification when target
has started running again. It also tried to get stack when target was running and
this caused randon failure.

Approved in http://lists.cs.uiuc.edu/pipermail/lldb-dev/2015-March/006953.html

llvm-svn: 232370

llvm-svn: 232368

Summary: This patch consists of the suggestions of clang-tidy/misc-static-assert check.

Reviewers: alexfh

Subscribers: dblaikie, xazax.hun, cfe-commits

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

Patch by Szabolcs Sipos!

llvm-svn: 232367

Summary:
This patch consists of the suggestions of clang-tidy/misc-static-assert check.


Reviewers: alexfh

Reviewed By: alexfh

Subscribers: xazax.hun, llvm-commits

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

llvm-svn: 232366

The rest of the test uses the #defines for the locale names properly. In
this single spot we do hardcode the string. This causes this test to
fail on CloudABI, where this locale is called en_US.UTF-8@UTC.

llvm-svn: 232365

No functional changes.

llvm-svn: 232364

No functional changes.

llvm-svn: 232363

No functional changes.

llvm-svn: 232362

llvm-svn: 232361

llvm-svn: 232360

No functional changes.

llvm-svn: 232359

As pointed out in http://reviews.llvm.org/D7583
The current checks can cause overflows when object size/access offset cross Quintillion bytes.

http://reviews.llvm.org/D8193

llvm-svn: 232358

llvm-svn: 232357

llvm-svn: 232356

llvm-svn: 232355

This still doesn't actually work correctly for big endian input files,
but since these tests all use little endian input files they don't
actually fail. I'll be committing a real fix for big endian soon, but
I don't have proper tests for it yet.

llvm-svn: 232354

llvm-svn: 232353

llvm-svn: 232352

[objc-arc] Make the ARC optimizer more conservative by forcing it to be non-safe in both direction, but mitigate the problem by noting that we just care if there was a further use.

The problem here is the infamous one direction known safe. I was
hesitant to turn it off before b/c of the potential for regressions
without an actual bug from users hitting the problem. This is that bug ;
).

The main performance impact of having known safe in both directions is
that often times it is very difficult to find two releases without a use
in-between them since we are so conservative with determining potential
uses. The one direction known safe gets around that problem by taking
advantage of many situations where we have two retains in a row,
allowing us to avoid that problem. That being said, the one direction
known safe is unsafe. Consider the following situation:

retain(x)
retain(x)
call(x)
call(x)
release(x)

Then we know the following about the reference count of x:

// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
retain(x)
// rc(x) == N+2
call A(x)
call B(x)
// rc(x) >= 1 (since we can not release a deallocated pointer).
release(x)
// rc(x) >= 0

That is all the information that we can know statically. That means that
we know that A(x), B(x) together can release (x) at most N+1 times. Lets
say that we remove the inner retain, release pair.

// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
call A(x)
call B(x)
// rc(x) >= 1
release(x)
// rc(x) >= 0

We knew before that A(x), B(x) could release x up to N+1 times meaning
that rc(x) may be zero at the release(x). That is not safe. On the other
hand, consider the following situation where we have a must use of
release(x) that x must be kept alive for after the release(x)**. Then we
know that:

// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
retain(x)
// rc(x) == N+2
call A(x)
call B(x)
// rc(x) >= 2 (since we know that we are going to release x and that that release can not be the last use of x).
release(x)
// rc(x) >= 1 (since we can not deallocate the pointer since we have a must use after x).
…
// rc(x) >= 1
use(x)

Thus we know that statically the calls to A(x), B(x) can together only
release rc(x) N times. Thus if we remove the inner retain, release pair:

// rc(x) == N (for some N).
retain(x)
// rc(x) == N+1
call A(x)
call B(x)
// rc(x) >= 1
…
// rc(x) >= 1
use(x)

We are still safe unless in the final … there are unbalanced retains,
releases which would have caused the program to blow up anyways even
before optimization occurred. The simplest form of must use is an
additional release that has not been paired up with any retain (if we
had paired the release with a retain and removed it we would not have
the additional use). This fits nicely into the ARC framework since
basically what you do is say that given any nested releases regardless
of what is in between, the inner release is known safe. This enables us to get
back the lost performance.

<rdar://problem/19023795>

llvm-svn: 232351

This will be tested in the next commit (which required it). The commit
is going to update a bunch of tests at the same time.

llvm-svn: 232350

This is a name that is more descriptive of what the method really does. NFC.

llvm-svn: 232349

llvm-svn: 232348

[objc-arc] Change EntryPointType to an enum class outside of ARCRuntimeEntryPoints called ARCRuntimeEntryPointKind.

llvm-svn: 232347