This makes sure that the exit control flow that merges the try-block
with the catch-block after a try-catch-statement creates a new merge
node in cases where it has to. Otherwise dangling phi nodes might have
the wrong number of value inputs.

R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-505354
BUG=chromium:505354
LOG=N

Review URL: https://codereview.chromium.org/1213183003

Cr-Commit-Position: refs/heads/master@{#29362}

The failure was been triggered by turning on --harmony-arrays,
maybe because code size was increased or code was added later
in the bootstrap process. Because it doesn't look like a bug
in anything guarded by --harmony-arrays directly, I'd suggest
shipping the flag and disabling the test on the architectures
where it's been observed to fail. It's already disabled on arm64
and this patch disables it on mips64 as well.

BUG=v8:4200
LOG=N
R=adamk

Review URL: https://codereview.chromium.org/1212963004

Cr-Commit-Position: refs/heads/master@{#29361}

Port 7a63bf77

Original commit message:
This makes new.target work in [[Call]] and [[Construct]] of ordinary
functions.

We achieve this by introducing a new construct stub for functions that
uses the new.target variable. The construct stub pushes the original
constructor just above the receiver in the construct frame.

R=arv@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1213303002

Cr-Commit-Position: refs/heads/master@{#29360}

BUG=v8:3887
LOG=N
R=caitpotter88@gmail.com, adamk@chromium.org

Review URL: https://codereview.chromium.org/1215973005

Cr-Commit-Position: refs/heads/master@{#29359}

This makes new.target work in [[Call]] and [[Construct]] of ordinary
functions.

We achieve this by introducing a new construct stub for functions that
uses the new.target variable. The construct stub pushes the original
constructor just above the receiver in the construct frame.

BUG=v8:3887
LOG=N
R=adamk@chromium.org, dslomov@chromium.org

Review URL: https://codereview.chromium.org/1203813002

Cr-Commit-Position: refs/heads/master@{#29358}

We were calling the setter for Object.prototype.promise if it existed
when calling PromiseAll.

BUG=v9:4232
LOG=N
R=rossberg@chromium.org, adamk@chromium.org

Review URL: https://codereview.chromium.org/1219623005

Cr-Commit-Position: refs/heads/master@{#29357}

zlib is broken for mips after 35eb3a02.

We're still working on a fix. Skip test for now, so the bots cycle green.

BUG=

Review URL: https://codereview.chromium.org/1209253005

Cr-Commit-Position: refs/heads/master@{#29356}

BUG=chromium:505228
LOG=Y

Review URL: https://codereview.chromium.org/1219723002

Cr-Commit-Position: refs/heads/master@{#29355}

Only this way we can precisely determine how to allocate let variables
inside the scope.

R=rossberg@chromium.org
BUG=v8:4255
LOG=N

Review URL: https://codereview.chromium.org/1216013002

Cr-Commit-Position: refs/heads/master@{#29354}

Enable skipped test-api/RequestInterruptTestWith* after:
https://codereview.chromium.org/1220443002/

TEST=
BUG=

Review URL: https://codereview.chromium.org/1219683004

Cr-Commit-Position: refs/heads/master@{#29353}

Separated core greedy allocator concepts, exposing the APIs we would want to continue working with. In particular, this change completely reworks CoalescedLiveRanges to reflect the fact that we expect more than one possible conflict, scrapping the initial design of the structure. Since this is a critical part of the design, this change may be thought of as a full rewrite of the algorithm.

Reduced all heuristics to just 2 essential ones: split "somewhere", which we'll still need when all other heuristics fail; and spill.

Introduced a simple primitive for splitting - at GapPosition::START. The goal is to use such primitives to quickly and reliably author heuristics.

I expected this primitive to "just work" for any arbitrary instruction index within a live range - e.g. its middle. That's not the case, it seems to upset execution in certain scenarios. Restricting to either before/after use positions seems to work. I'm still investigating what the source of failures is in the case of "arbitrary instruction in the range" case.

I intended to document the rationale and prove the soundness of always using START for splits, but I will postpone to after this last remaining issue is resolved.

Review URL: https://codereview.chromium.org/1205173002

Cr-Commit-Position: refs/heads/master@{#29352}

This one occurs when Function.prototype.toString is overridden to return a
non-string.

BUG=chromium:504729
R=mstarzinger@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/1214803004

Cr-Commit-Position: refs/heads/master@{#29351}

Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on
report_exceptions in Shell::ExecuteString, but instead I turned on print_result
(which assumes an interactive debugger and a HandleScope for the
utility_context_).

BUG=chromium:504727,chromium:504728
R=mstarzinger@chromium.org
LOG=n

Review URL: https://codereview.chromium.org/1219563002

Cr-Commit-Position: refs/heads/master@{#29350}

The android_* configs were never real v8 target
architectures, only make targets. This doesn't make sense
with ninja anymore.

BUG=chromium:502176
LOG=n
NOTRY=true

Review URL: https://codereview.chromium.org/1220743002

Cr-Commit-Position: refs/heads/master@{#29349}

BUG=chromium:505367
LOG=N

Review URL: https://codereview.chromium.org/1215003002

Cr-Commit-Position: refs/heads/master@{#29348}

RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent.

Review URL: https://codereview.chromium.org/1207433002

Cr-Commit-Position: refs/heads/master@{#29347}

BUG=505228
LOG=Y

Review URL: https://codereview.chromium.org/1210153003

Cr-Commit-Position: refs/heads/master@{#29346}

Revert of Use third_party clang on Mac. (patchset #4 id:60001 of https://codereview.chromium.org/1200833013/)

Reason for revert:
[Sheriff] Breaks mac on the main waterfall (though not on the tryserver):
http://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/3925

Original issue's description:
> Use third_party clang on Mac.
>
> BUG=
>
> Committed: https://crrev.com/57b20413294940476ab2b2e71ed0802aaf8c223f
> Cr-Commit-Position: refs/heads/master@{#29343}

TBR=danno@chromium.org,jkummerow@chromium.org,paul.lind@imgtec.com,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

Review URL: https://codereview.chromium.org/1217823003

Cr-Commit-Position: refs/heads/master@{#29345}

Cr-Commit-Position: refs/heads/master@{#29344}

BUG=

Review URL: https://codereview.chromium.org/1200833013

Cr-Commit-Position: refs/heads/master@{#29343}

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/1212163003

Cr-Commit-Position: refs/heads/master@{#29342}

Make clang dir absolute to avoid differences between ninja
and make gyp generator.

BUG=chromium:502176
LOG=n

Review URL: https://codereview.chromium.org/1217783002

Cr-Commit-Position: refs/heads/master@{#29341}

R=jarin@chromium.org

Review URL: https://codereview.chromium.org/1218773002

Cr-Commit-Position: refs/heads/master@{#29340}

Report builtins by name (e.g. "Builtin:ArgumentsAdaptorTrampoline")
instead of labeling everything "Builtin:A builtin from the snapshot".

BUG=

Review URL: https://codereview.chromium.org/1216833002

Cr-Commit-Position: refs/heads/master@{#29339}

Fix c/p error from https://codereview.chromium.org/1217483002/

TBR=jochen@chromium.org

Review URL: https://codereview.chromium.org/1214013002

Cr-Commit-Position: refs/heads/master@{#29338}

R=wingo@igalia.com
BUG=v8:811
LOG=N

Review URL: https://codereview.chromium.org/1212473002

Cr-Commit-Position: refs/heads/master@{#29337}

Move class tests to es6 directory

BUG=v8:3330
LOG=N
R=adamk

Review URL: https://codereview.chromium.org/1213813003

Cr-Commit-Position: refs/heads/master@{#29336}

Port 8a3cf4ec

R=mvstanton@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1212613003

Cr-Commit-Position: refs/heads/master@{#29335}

And move tests to es6 directory

BUG=v8:3516
LOG=N
R=adamk@chromium.org, rossberg@chromium.org

Review URL: https://codereview.chromium.org/1218473003

Cr-Commit-Position: refs/heads/master@{#29334}

Port 2b9112a5

Original commit message:
This optimization is already implemented in fullcodegen, and
basically makes sure that we do not unecessarily blow up the
code with duplicated return sequences everywhere.

R=bmeurer@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
BUG=

Review URL: https://codereview.chromium.org/1218493003

Cr-Commit-Position: refs/heads/master@{#29333}

The test language/asi/S7.9_A5.7_T1 is failing intermittently.

BUG=v8:4253
LOG=N
TBR=adamk

Review URL: https://codereview.chromium.org/1215813002.

Cr-Commit-Position: refs/heads/master@{#29332}

The use of jalr ra is unpredictable if instruction in branch delay slot
is in next page.

This finally fixes random failures in JS debugger and InteruptRequest tests.

TEST=mjsunit/debug-*,
     cctest/test-api/RequestInterruptTestWithNativeAccessor
BUG=

Review URL: https://codereview.chromium.org/1220443002

Cr-Commit-Position: refs/heads/master@{#29331}

This is a step towards having Blink no longer look directly at the
line endings array.  That prevented https://codereview.chromium.org/1137683003/
from landing.  Next step, after the roll, will be using these
functions in Blink.
R=jochen@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1213783002

Cr-Commit-Position: refs/heads/master@{#29330}

File bugs for all failing tests in test262-es6.

There are still some old "needs investigation" failures that I didn't
investigate.

BUG=N
LOG=N
R=littledan@chromium.org, adamk@chromium.org

Review URL: https://codereview.chromium.org/1209163002

Cr-Commit-Position: refs/heads/master@{#29329}

BUG=

Review URL: https://codereview.chromium.org/1217483002

Cr-Commit-Position: refs/heads/master@{#29328}

Now that we keep tabs on shared function infos from a script, we can speed up finding shared function infos for debugging. However, in case we have to compile a function that cannot be lazily compiled without context, we fall back to the slow heap iteration.

R=mstarzinger@chromium.org
BUG=v8:4132,v8:4052
LOG=N

Committed: https://crrev.com/cfe89a71a332ef9ed481c8210bc3ad6d2822034b
Cr-Commit-Position: refs/heads/master@{#29296}

Review URL: https://codereview.chromium.org/1206573004

Cr-Commit-Position: refs/heads/master@{#29327}

Note that prior to having canonical shared function infos, this has
been a source of duplicate shared function infos.

R=bmeurer@chromium.org
BUG=chromium:504787
LOG=N

Review URL: https://codereview.chromium.org/1209383002

Cr-Commit-Position: refs/heads/master@{#29326}

BUG=

Review URL: https://codereview.chromium.org/1205843005

Cr-Commit-Position: refs/heads/master@{#29325}

R=svenpanne@chromium.org

Review URL: https://codereview.chromium.org/1218443002

Cr-Commit-Position: refs/heads/master@{#29324}

This reverts commit e93e4dad.

BUG=chromium:502176
LOG=n
NOTRY=true
TBR=ulan@chromium.org, jochen@chromium.org

Review URL: https://codereview.chromium.org/1213803002

Cr-Commit-Position: refs/heads/master@{#29323}