This enables tests which rely on the context available at "debugger"
statements to be accurate. This is the case by now when deoptimization
information is available.

R=mvstanton@chromium.org
BUG=v8:4035

Review-Url: https://codereview.chromium.org/2125773005
Cr-Commit-Position: refs/heads/master@{#37590}

R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2127093002
Cr-Commit-Position: refs/heads/master@{#37589}

Review-Url: https://codereview.chromium.org/2110343003
Cr-Commit-Position: refs/heads/master@{#37588}

This should recover the regression caused by https://codereview.chromium.org/1993653003.
(Same sympthoms as in http://crbug/619016).

BUG=chromium:624309

Review-Url: https://codereview.chromium.org/2127103002
Cr-Commit-Position: refs/heads/master@{#37587}

Port de369129

Original commit message:

In the current implementation of wasm an unrepresentable input of the
float32-to-int32 conversion is detected by first truncating the input, then
converting the truncated input to int32 and back to float32, and then checking
whether the result is the same as the truncated input.

This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
because on these platforms the float32-to-int32 conversion results in INT32_MAX
if the input is greater than INT32_MAX.  When INT32_MAX is converted back to
float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
+ 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
to be representable.

With the changes in this CL, the result of the float32-to-int32 conversion is
incremented by 1 if the original result was INT32_MAX. Thereby the detection of
unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
represented precisely in float32, it can also never be a valid result of the
float32-to-int32 conversion.

BUG=cctest/test-run-wasm/RunWasmCompiled_I32SConvertF32,cctest/test-run-wasm/RunWasmCompiled_I32UConvertF32

Review-Url: https://codereview.chromium.org/2130763002
Cr-Commit-Position: refs/heads/master@{#37586}

Now LookupIterator follows the same pattern of prepare transition, apply transition
and write value when adding new properties to dictionary objects.

JSGlobalObject case:
* Prepare transition phase ensures that there is a "transition" property cell
  prepared for receiving a value.
* Apply transition phase does nothing.
* Prepare for data property phase ensures that the existing property cell can
  receive the value.
* Write value phase writes value directly to the current property cell.

JSObject case:
* Prepare transition phase prepares the object for receiving a data value (which
  could switch an object to dictionary mode).
* Apply transition phase migrates object to a transition map. If the map happened
  to be a dictionary mode object's map then an uninitialized entry added to the
  properties dictionary.
* Prepare for data property phase does nothing.
* Write value phase just puts value to the properties dictionary.

BUG=chromium:576312

Review-Url: https://codereview.chromium.org/2127583002
Cr-Commit-Position: refs/heads/master@{#37585}

R=mvstanton@chromium.org
BUG=v8:4458

Review-Url: https://codereview.chromium.org/2129903002
Cr-Commit-Position: refs/heads/master@{#37584}

R=mvstanton@chromium.org

Review-Url: https://codereview.chromium.org/2132503002
Cr-Commit-Position: refs/heads/master@{#37583}

In AstNumberingVisitor we always know what node we're dealing with, so there's no reason for this method to be virtual. This additionally deletes 3 calls to AssignFeedbackVectorSlots that would always end up in the empty version.

BUG=

Review-Url: https://codereview.chromium.org/2128613003
Cr-Commit-Position: refs/heads/master@{#37582}

For motivation see the bug.

BUG=625865
LOG=NO

Review-Url: https://codereview.chromium.org/2121273002
Cr-Commit-Position: refs/heads/master@{#37581}

BUG=chromium:474921

Review-Url: https://codereview.chromium.org/2124263002
Cr-Commit-Position: refs/heads/master@{#37580}

BUG=chromium:474921
NOTRY=true
TBR=vogelheim@chromium.org, jochen@chromium.org

Review-Url: https://codereview.chromium.org/2130723002
Cr-Commit-Position: refs/heads/master@{#37579}

BUG=chromium:626256
LOG=NO

Review-Url: https://codereview.chromium.org/2126193002
Cr-Commit-Position: refs/heads/master@{#37578}

BUG=v8:5181

Review-Url: https://codereview.chromium.org/2129563002
Cr-Commit-Position: refs/heads/master@{#37577}

This changes the last few remaining RUNTIME_ASSERT calls that need to be
intentionally robust because fuzzers or other callers can invoke the
runtime functions in question with unsafe arguments.

R=yangguo@chromium.org
BUG=v8:5066

Review-Url: https://codereview.chromium.org/2122173003
Cr-Commit-Position: refs/heads/master@{#37576}

BUG=chromium:474921
TBR=jochen@chromium.org, vogelheim@chromium.org,
NOTRY=true

Review-Url: https://codereview.chromium.org/2124003003
Cr-Commit-Position: refs/heads/master@{#37575}

Needed for https://codereview.chromium.org/2124263002/

BUG=chromium:474921
TBR=jochen@chromium.org, vogelheim@chromium.org,
NOTRY=true

Review-Url: https://codereview.chromium.org/2125703005
Cr-Commit-Position: refs/heads/master@{#37574}

BUG=chromium:474921
NOTRY=true
TBR=vogelheim@chromium.org, jochen@chromium.org

Review-Url: https://codereview.chromium.org/2129853002
Cr-Commit-Position: refs/heads/master@{#37573}

Those virtual methods shouldn't live on the AST since they are crankshaft specific, and can easily be checked inline.

BUG=

Review-Url: https://codereview.chromium.org/2125933004
Cr-Commit-Position: refs/heads/master@{#37572}

When reading the value property of an iterator result fails, we must not close the iterator.
This was not discovered earlier because the tests had a subtle bug.

This CL fixes both the desugaring and the tests.

BUG=

Review-Url: https://codereview.chromium.org/2119353002
Cr-Commit-Position: refs/heads/master@{#37571}

A bit of browsing around indicates that the new fast-path is taken most of the time:
   3496 Entering new
 152295 Reentering same

BUG=

Review-Url: https://codereview.chromium.org/2131483002
Cr-Commit-Position: refs/heads/master@{#37570}

For variables introduced as part of a catch pattern, we used to set their
"initializer position" to the beginning of the pattern.  This lead to
full-codegen eliminating crucial hole checks when reading such variables
inside the pattern itself.

R=adamk@chromium.org, littledan@chromium.org
BUG=v8:5178

Review-Url: https://codereview.chromium.org/2123953002
Cr-Commit-Position: refs/heads/master@{#37569}

Rolling v8/build to 6d9becf753310daf17f04ac4f0d8c109c364cdd2

Rolling v8/buildtools to aa47d9773d8f4d6254a587a1240b3dc023d54f06

Rolling v8/tools/gyp to bac4680ec9a5c55ab692490b6732999648ecf1e9

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Review-Url: https://codereview.chromium.org/2123853004
Cr-Commit-Position: refs/heads/master@{#37568}

Port b86ac0e0

Original commit message:

    Both of these were broken in different ways:
    * On arm, the loop counter was passed as argc on the stack.
    * On arm64, we passed argc + 1 instead of argc.

    The result in both cases was an incorrect receiver for the builtin frame
    when generating stack traces.

R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4815
LOG=N

Review-Url: https://codereview.chromium.org/2125913004
Cr-Commit-Position: refs/heads/master@{#37567}

Revert of [esnext] ship --harmony-object-values-entries (patchset #1 id:1 of https://codereview.chromium.org/2116053003/ )

Reason for revert:
Revert to see if it addresses the performance regression observed in chromium:625956 in automated graphs

Original issue's description:
> [esnext] ship --harmony-object-values-entries
>
> BUG=v8:4663
> R=littledan@chromium.org, adamk@chromium.org
>
> Committed: https://crrev.com/ab529234853a1768642f8f6c907aaaa5ea8b19bf
> Cr-Commit-Position: refs/heads/master@{#37485}

TBR=adamk@chromium.org,caitpotter88@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:4663

Review-Url: https://codereview.chromium.org/2129533004
Cr-Commit-Position: refs/heads/master@{#37566}

Working on eliminating the use of ClassOf(). This function was checking IS_ARRAYBUFFER.

BUG=

Review-Url: https://codereview.chromium.org/2126603003
Cr-Commit-Position: refs/heads/master@{#37565}

We want to eventually move the profiling functionality out of V8 as library,
this patch exposes TickSample and its APIs in v8-profiler.h so that when
embedders use library, they can have more details.

Minor change: Rename tick-sample.[h|cc] to simulator-helper.[h|cc].

BUG=v8:4789
LOG=N

Review-Url: https://codereview.chromium.org/2105943002
Cr-Commit-Position: refs/heads/master@{#37564}

Port f59a2335

Original commit message:

    Stack trace generation requires access to the receiver; and while the
    receiver is already on the stack, we cannot determine its position
    during stack trace generation (it's stored in argv[0], and argc is only
    stored in a callee-saved register).

    This patch grants access to the receiver by pushing argc onto builtin
    exit frames as an extra argument. Compared to simply pushing the
    receiver, this requires an additional dereference during stack trace
    generation, but one fewer during builtin calls.

R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=v8:4815
LOG=N

Review-Url: https://codereview.chromium.org/2129643002
Cr-Commit-Position: refs/heads/master@{#37563}

PPC: [fullcode][mips][mips64][ppc][s390] Avoid trashing of a home object when doing a keyed store to a super.

Port 43aee033

    Fixed minor typo in ppc file.

R=ishell@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=chromium:625590
LOG=N

Review-Url: https://codereview.chromium.org/2125933002
Cr-Commit-Position: refs/heads/master@{#37562}

Port bd0d9e7d

Original commit message:

    This optimizes the passing of stack parameters in function calls.

    For some architectures (ia32/x64), using pushes when possible instead
    of bumping the stack and then storing parameters generates much
    smaller code, and in some cases is faster (e.g. when a push of a memory
    location can implement a memory-to-memory copy and thus elide an
    intermediate load. On others (e.g. ARM), the benefit is smaller, where
    it's only possible to elide direct stack pointer adjustment in certain cases
    or combine multiple register stores into a single instruction in other limited
    situations. On yet other platforms (ARM64, MIPS), there are no push instructions,
    and this optimization isn't used at all.

    Ideally, this mechanism would be used for both tail calls and normal calls,
    but "normal" calls are currently pretty efficient, and tail calls are very
    inefficient, so this CL sets the bar low for building a new mechanism to
    handle parameter pushing that only needs to raise the bar on tail calls for now.

    The key aspect of this change is that adjustment to the stack pointer
    for tail calls (and perhaps later real calls) is an explicit step separate from
    instruction selection and gap resolution, but aware of both, making it possible
    to safely recognize gap moves that are actually pushes.

R=danno@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2123983002
Cr-Commit-Position: refs/heads/master@{#37561}

Add temporary bots that continuously test with gyp until its
deprecation.

BUG=chromium:474921
NOTRY=true

Review-Url: https://codereview.chromium.org/2123173002
Cr-Commit-Position: refs/heads/master@{#37560}

And in so doing, enable a handful of excluded tests.

BUG=

Review-Url: https://codereview.chromium.org/2127713003
Cr-Commit-Position: refs/heads/master@{#37559}

Reland of [gn] Switch more linux32 bots to gn (patchset #1 id:1 of https://codereview.chromium.org/2128493002/ )

Reason for revert:
Should be fixed after https://codereview.chromium.org/2123223002/

Original issue's description:
> Revert of [gn] Switch more linux32 bots to gn (patchset #3 id:40001 of https://codereview.chromium.org/2122933002/ )
>
> Reason for revert:
> Breaks test isolation on shared library bot.
>
> Original issue's description:
> > [gn] Switch more linux32 bots to gn
> >
> > This switches nosnap and shared library bots to gn.
> >
> > This also unsets external startup data if no snapshot is
> > used.
> >
> > BUG=chromium:474921
> > NOTRY=true
> >
> > Committed: https://crrev.com/ab4d8fc07d9d35e6fc129098f42aa0317a02244a
> > Cr-Commit-Position: refs/heads/master@{#37546}
>
> TBR=vogelheim@chromium.org,jochen@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:474921
>
> Committed: https://crrev.com/a5fa2984257a50ee9440914c7d1a199f64a86194
> Cr-Commit-Position: refs/heads/master@{#37548}

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

Review-Url: https://codereview.chromium.org/2126843002
Cr-Commit-Position: refs/heads/master@{#37558}

HashField is a 32-bit field.

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

Review-Url: https://codereview.chromium.org/2117403002
Cr-Commit-Position: refs/heads/master@{#37557}

Because the release_bot mixin includes the 'static' config,
the shared-library bots included both 'static' and 'shared'.

This removes the wrong 'static' config.

BUG=chromium:474921
TBR=vogelheim@chromium.org, jochen@chromium.org

Review-Url: https://codereview.chromium.org/2123243002
Cr-Commit-Position: refs/heads/master@{#37556}

This version of the isolate_driver includes a feature
that automatically derives shared libraries for inclusion.

This is needed for GN as the shared library location is
different compared to gyp and having different configs
would be tedious.

This also removes the shared-library-specific configs as
they are no longer needed with the new driver.

BUG=chromium:474921

Review-Url: https://codereview.chromium.org/2123223002
Cr-Commit-Position: refs/heads/master@{#37555}

R=rossberg@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2127833002
Cr-Commit-Position: refs/heads/master@{#37554}

BUG=v8:5105

Review-Url: https://codereview.chromium.org/2126693003
Cr-Commit-Position: refs/heads/master@{#37553}

Revert of Add crash instrumentation for crbug.com/621147 (patchset #1 id:1 of https://codereview.chromium.org/2114743002/ )

Reason for revert:
Bug found and fixed: crrev.com/7614362b

Instrumentation no longer needed.

Original issue's description:
> Add crash instrumentation for crbug.com/621147
>
> BUG=chromium:621147
> LOG=N
> R=ishell@chromium.org,cbruni@chromium.org
>
> Committed: https://crrev.com/5ff508a82299f20a0d9828cf73072a4f4772fab8
> Cr-Commit-Position: refs/heads/master@{#37328}

TBR=verwaest@chromium.org,cbruni@chromium.org,ishell@chromium.org,mlippautz@chromium.org,adamk@chromium.org
BUG=chromium:621147, chromium:624764

Review-Url: https://codereview.chromium.org/2127813002
Cr-Commit-Position: refs/heads/master@{#37552}

While the test was useful to reproduce the issue locally it creates a lot of
heap pressure and causes all sorts of troubles (OOM, slowness) on the bots, so
let's drop it.

R=hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2127803002
Cr-Commit-Position: refs/heads/master@{#37551}