We need one message in case the function is not an object, and
another if it was an object but not callable.

R=mstarzinger@chromium.org, rossberg@chromium.org
BUG=

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

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

BUG=chromium:568949
LOG=n
TBR=kjellander@chromium.org, tandrii@chromium.org
NOTRY=true

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

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

R=yangguo@chromium.org

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

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

  port 2aa070be (r34863)

  original commit message:
  Repair this to match what the runtime correctly does, by first checking if the
  function is a constructor before we access the prototype.

BUG=

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

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

  port 992ae64d (r34866)

  original commit message:
  This new intrinsic is used by the desugared ES6 instanceof implementation for
  the cases when the F[@@hasInstance] property is null or undefined.

BUG=

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

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

It was never being set to false in production (though it was in test-parsing.cc,
due to that test having its own flag-setting logic).

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

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

Revert of [heap] Enable black allocation. (patchset #1 id:1 of https://codereview.chromium.org/1809983002/ )

Reason for revert:
Continues to cause flaky GPU test failures on Chromium waterfall.
See details at http://crbug.com/595092#c22

Original issue's description:
> [heap] Enable black allocation.
>
> BUG=
>
> Committed: https://crrev.com/447b1156d3bb4aa693175b74780104329ccd41ea
> Cr-Commit-Position: refs/heads/master@{#34847}

TBR=mlippautz@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:595092

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

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

This patch fixes two bugs in Array.prototype.concat in conjunction with
subclassing Arrays:
- Create a new property rather than calling Set when adding elements to
  the output array. This means setters are not called.
- If there is an exception thrown from DefineProperty, propagate it
  outwards properly, rather than swallowing it. This can occur, e.g., with
  a Proxy as the new output array.

R=adamk
LOG=Y
BUG=chromium:595319

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

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

Previously, when a property was non-configurable or the object was
non-extensible, CreateDataProperty might just return false rather than
throwing, even if should_throw was on. This patch fixes that issue.

Tested by running the patch at https://codereview.chromium.org/1814933002
on top of this code and observing the tests to see an exception thrown.

R=adamk
BUG=chromium:595319
LOG=Y

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

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

This reverts commit 4857110c.

This change was flushing out another issue which is fixed in
  https://codereview.chromium.org/1783283003/

BUG=v8:2999
LOG=N

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

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

Port 992ae64d

Original commit message:
    This new intrinsic is used by the desugared ES6 instanceof implementation for
    the cases when the F[@@hasInstance] property is null or undefined.

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

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

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

Port 2aa070be

Original commit message:
    Repair this to match what the runtime correctly does, by first checking if the
    function is a constructor before we access the prototype.

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

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

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

Port 992ae64d

Original commit message:
    This new intrinsic is used by the desugared ES6 instanceof implementation for
    the cases when the F[@@hasInstance] property is null or undefined.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

Port 2aa070be

Original commit message:
    Repair this to match what the runtime correctly does, by first checking if the
    function is a constructor before we access the prototype.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

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

BUG=595259
LOG=N

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

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

Functions with builtin ids can be compiled with Ignition, so it is no longer
an option to overlap the bytecode_array field with the builtin id on
the SharedFunctionInfo object. Instead overlap it with the
inferred_name, which is only used for debug and so shouldn't be required
for functions with builtin ids. This result in the inferred_name field
being renamed to function_identifier, and adding typed accessors for
inferred_name and builtin_function_id.

This is required to build the snapshot with --no-lazy.

BUG=v8:4280
LOG=N

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

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

This new intrinsic is used by the desugared ES6 instanceof implementation for
the cases when the F[@@hasInstance] property is null or undefined.

R=mstarzinger@chromium.org

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

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

    Port 33c08596

    Original commit message:
        Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
        operator takes 4 inputs an generates 2 outputs. The inputs are the low
        word of the left input, high word of the left input, the low word of the
        right input, and high word of the right input. The ouputs are the low
        and high word of the result of the subtraction.

        The implementation is very similar to the implementation of Int64Add.

R=ahaas@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

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

R=mstarzinger@chromium.org
TBR=rossberg
BUG=

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

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

Repair this to match what the runtime correctly does, by first checking if the
function is a constructor before we access the prototype.

R=verwaest@chromium.org
BUG=

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

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

Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions for the use of a memory operand are met.

This CL makes it possible to load only one of them into a register and address the other as a memory operand.

Meanwhile, comparisons between Uint8 values in the string relational comparison stubs are done with Uint32LessThan (previously we were always zero-extending the byte to a 32-bit value, so signed comparison was alright).

Found that Assembler::arithmetic_op_8(byte, Register, const Operand&) wasn't taking the Operand's rex_ field into account, so I fixed that too.

BUG=

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

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

BUG=chromium:524425
LOG=N

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

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

Port 879d254d

Original commit message:
Landing this again, excluding arm as it fail and arm64
out of caution that other wasm arm64 tests are also disabled.

BUG= https://code.google.com/p/v8/issues/detail?id=4203
TEST=mjsunit/asm-wasm
LOG=N

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

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

Immortal immovable roots must be allocated on the first page of the space.
If serializing the root list exceeds the first page, immortal immovable root
objects might end up outside of the first page. That could cause missing
write barriers.

We now iterate the root list twice. The first time we only serialize immortal
immovable root objects. The second time we serialize the rest.

R=mstarzinger@chromium.org

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

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

The new location allows to add an external reference without requiring
an lgtm from a snapshot/ owner.

R=yangguo@chromium.org

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

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

GCC on S390 31-bit treats size_t as 'long unsigned int', which
is incompatible with %d format specifier that expects an 'int'.
Introduce a new V8 SIZET PREFIX to use %zd instead.

R=danno@chromium.org,jkummerow@chromium.org,jochen@chromium.org,jyan@ca.ibm.com,michael_dawson@ca.ibm.com,mbrandy@us.ibm.com,yangguo@chromium.org
BUG=

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

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

HandleScopes in for-loops are rather expensive and pose a significant overhead
to some builtin/runtime-functions. The FOR_WITH_HANDLE_SCOPE macro is used to
only create a new HandleScope every 1024th iteration.

BUG=

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

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

The way desugared instanceof called OrdinaryHasInstance if the lookup of
@@hasInstance failed was incorrect.

BUG=v8:4774
LOG=N

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

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

R=titzer@chromium.org

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

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

Before this CL, free memory (FreeSpace) has been managed through a global free
list that contains single-linked lists of FreeSpace nodes for each size class.

We move away from this approach to a global two-level doubly-linked list that
refers to singly-linked lists of FreeSpace nodes on the corresponding pages.
This way we can refill on a page-level granularity. Furthermore, it also enables
constant-time eviction of pages from the free list.

BUG=chromium:524425
LOG=N

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

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

(The goal is to have CodeStubAssembler be the sole assembler-like user of
the TF compiler pipeline; with RMA being a private implementation detail
and FAA being a client.)

BUG=chromium:508898
LOG=Y

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

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

* New and old space pages have the same allocatable memory size
* Enforce declaration order in NewSpacePage

BUG=chromium:581412
LOG=N

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

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

NOTRY=true
NOTREECHECKS=true
TBR=machenbach@chromium.org

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

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

A startup snapshot is considered cold when it does not contain any
function code. We can now create a warm startup snapshot from a cold one
by running a warm-up script. Functions exercised by the warm-up script
are compiled and its code included in the warm startup snapshot. Side
effects caused by the warm-up script does not persist.

R=vogelheim@chromium.org
BUG=v8:4836
LOG=Y

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

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

BUG=v8:4839
LOG=n

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

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

BUG=

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

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

If the variable is unallocated, say so.

This CL also fixes the return value of FormatSlotNode.

R=mvstanton@chromium.org
TBR=rossberg@chromium.org
BUG=

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

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

  port e1a7c1e7 (r34836)

  original commit message:
   - New RelocInfo mode WASM_MEMORY_REFERENCE as a marker for wasm code objects that need to be relocated on a heap change
   - RelocInfo mode recorded for immediates that use the memory buffer as base
   - Tests to verify address patching works

BUG=

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

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

  port 33c08596 (r34808)

  original commit message:
  Int64Sub is lowered to a new turbofan operator, Int32SubPair. The new
  operator takes 4 inputs an generates 2 outputs. The inputs are the low
  word of the left input, high word of the left input, the low word of the
  right input, and high word of the right input. The ouputs are the low
  and high word of the result of the subtraction.

  The implementation is very similar to the implementation of Int64Add.

  @v8-arm-ports: please take a careful look at the implementation of sbc
  in the simulator

BUG=

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

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