Rename the existing (patching) ToBooleanStub to ToBooleanICStub to match
our naming convention, and add a new TurboFan-powered ToBooleanStub,
which just does the ToBoolean conversion without any runtime call or
code patching, so we can use it for Ignition (and TurboFan).

Drive-by-fix: Add an Oddball::to_boolean field similar to the ones we
already have for to_string and to_number, so we don't need to actually
dispatch on the concrete Oddball at all.

R=epertoso@chromium.org, rmcilroy@chromium.org, yangguo@chromium.org

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

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

BUG=v8:2999, v8:4751
LOG=n

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

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

Given that an additional map-check is inserted for function, we need to
check the underlying value.

BUG=

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

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

R=jkummerow@chromium.org

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

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

Probably easier to use for embedders.

BUG=
R=ulan@chromium.org

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

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

This gets rid of the JavaScript wrapper. That way we can more quickly handle non-JSReceivers and indexed properties; and don't need to optimize the JavaScript wrapper either.

BUG=

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

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

Fix some crashes when tests are run on real hardware.

R=bmeurer@chromium.org

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

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

This ensures that the generated code output will match the reference code output
and fixes some failures when running tests natively.

R=bmeurer@chromium.org

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

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

  port fcb83f20(r34273)

  original commit message:
  This optimization does not give us much (see perf try bot results associated with this CL) but complicates things a lot. The main motivation is to avoid additional complexity in tail call optim

  There are some pieces left in the deoptimizer, but I'll address this in a separate CL.

BUG=

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

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

  port 55b4df73(r34303)

  original commit message:
  Only use one set of %StrictEquals/%StrictNotEquals and
  %Equals/%NotEquals runtime entries for both the interpreter
  and the old-style CompareICStub. The long-term plan is to
  update the CompareICStub to also return boolean values, and
  even allow some more code sharing with the interpreter there.

BUG=

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

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

R=bradnelson@chromium.org,ahaas@chromium.org
BUG=

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

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

R=bradnelson@chromium.org, binji@chromium.org
BUG=

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

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

This is just a band-aid workaround.

TBR=hablich@chromium.org
NOTRY=true

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

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

BUG=chromium:535160,v8:4792
LOG=n
TBR=tandrii@chromium.org, jkummerow@chromium.org

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

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

TBR=machenbach@chromium.org
NOTRY=true

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

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

R=binji@chromium.org,jfb@chromium.org
BUG=

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

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

R=bradnelson@chromium.org,aseemgarg@chromium.org
BUG=

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

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

Since both null and undefined are also marked as undetectable now, we
can just test that bit instead of having the CompareNilIC try to collect
feedback to speed up the general case (without the undetectable bit
being used).

Drive-by-fix: Update the type system to match the new handling of
undetectable in the runtime.

R=danno@chromium.org

Committed: https://crrev.com/666aec0348c8793e61c8633dee7ad29a514239ba
Cr-Commit-Position: refs/heads/master@{#34237}

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

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

Rolling v8/tools/clang to e67c4fe288f02e1d208961b757ff78d5b3e51782

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

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

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

R=binji@chromium.org,jfb@chromium.org
BUG=

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

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

Port d00da47b

Original commit message:
    The CompareICStub produces an untagged raw word value, which has to be
    translated to true or false manually in the TurboFan code. But for lazy
    bailout after the CompareIC, we immediately go back to fullcodegen or
    Ignition with the raw value, to a location where both fullcodegen and
    Ignition expect a boolean value, which might crash or in the worst case
    (depending on the exact computation inside the CompareIC) could lead to
    arbitrary memory access.

    Short-term fix is to use the proper runtime functions (unified with the
    interpreter now) for comparisons. Next task is to provide optimized
    versions of these based on the CodeStubAssembler, which can then be used
    via code stubs in TurboFan or directly in handlers in the interpreter.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:4788
LOG=n

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

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

Revert of PPC: [compiler] Drop the CompareNilIC. (patchset #1 id:1 of https://codereview.chromium.org/1733663003/ )

Reason for revert:
Original commit reverted.

Original issue's description:
> PPC: [compiler] Drop the CompareNilIC.
>
> Port 666aec03
>
> Original commit message:
>     Since both null and undefined are also marked as undetectable now, we
>     can just test that bit instead of having the CompareNilIC try to collect
>     feedback to speed up the general case (without the undetectable bit
>     being used).
>
>     Drive-by-fix: Update the type system to match the new handling of
>     undetectable in the runtime.
>
> R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
>
> Committed: https://crrev.com/546ea6b8393a894f07597ade5ec1c7db02c1e425
> Cr-Commit-Position: refs/heads/master@{#34266}

TBR=bmeurer@chromium.org,joransiu@ca.ibm.com,jyan@ca.ibm.com,michael_dawson@ca.ibm.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=

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

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

ES2015 allows strict mode block scoped function declarations; weaken
the error message about misuse to allow this.

BUG=v8:2198
LOG=Y
R=adamk

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

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

Reland of Test262 roll, 2016-2-23 (patchset #1 id:1 of https://codereview.chromium.org/1736223002/ )

Reason for revert:
Intl change relanded https://codereview.chromium.org/1745483002/

Original issue's description:
> Revert of Test262 roll, 2016-2-23 (patchset #2 id:20001 of https://codereview.chromium.org/1738033002/ )
>
> Reason for revert:
> An Intl change that this depends on breaks a bot
>
> Original issue's description:
> > Test262 roll, 2016-2-23
> >
> > R=adamk
> >
> > Committed: https://crrev.com/34492040fbfb04fead21416245c8696b9847e751
> > Cr-Commit-Position: refs/heads/master@{#34312}
>
> TBR=adamk@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/3b829ad80628bf521aa78255c2e5e20040a57b5f
> Cr-Commit-Position: refs/heads/master@{#34313}

TBR=adamk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

Reland of Make Intl install properties more like how other builtins do (patchset #1 id:1 of https://codereview.chromium.org/1733293003/ )

This reland fixes a bug by pulling properties off the utils object, so
that it can be garbage collected in nosnap builds.
Original commit message:

Intl has been somewhat of an oddball for how it integrates with V8.
One aspect is that it largely didn't use utils to install itself
into the snapshot, which led to some missing names, which new
test262 tests check for, and duplicated code. This patch brings
Intl a bit closer to how the rest of the builtins do things, though
not entirely as it is currently structured to do unusual things,
such as creating new constructors from JavaScript rather than C++.
New test262 tests check for some of the names that are added in
this patch.

R=adamk
CC=jshin
BUG=v8:4778
LOG=Y

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

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

Port 3ef573e9

Original commit message:

    Replace the somewhat awkward RestParamAccessStub, which would always
    call into the runtime anyway with a proper FastNewRestParameterStub,
    which is basically based on the code that was already there for strict
    arguments object materialization. But for rest parameters we could
    optimize even further (leading to 8-10x improvements for functions with
    rest parameters), by fixing the internal formal parameter count:

    Every SharedFunctionInfo has a formal_parameter_count field, which
    specifies the number of formal parameters, and is used to decide whether
    we need to create an arguments adaptor frame when calling a function
    (i.e. if there's a mismatch between the actual and expected parameters).
    Previously the formal_parameter_count included the rest parameter, which
    was sort of unfortunate, as that meant that calling a function with only
    the non-rest parameters still required an arguments adaptor (plus some
    other oddities). Now with this CL we fix, so that we do no longer
    include the rest parameter in that count. Thereby checking for rest
    parameters is very efficient, as we only need to check whether there is
    an arguments adaptor frame, and if not create an empty array, otherwise
    check whether the arguments adaptor frame has more parameters than
    specified by the formal_parameter_count.

    The FastNewRestParameterStub is written in a way that it can be directly
    used by Ignition as well, and with some tweaks to the TurboFan backends
    and the CodeStubAssembler, we should be able to rewrite it as
    TurboFanCodeStub in the near future.

    Drive-by-fix: Refactor and unify the CreateArgumentsType which was
    different in TurboFan and Ignition; now we have a single enum class
    which is used in both TurboFan and Ignition.

TEST=test/mjsunit/harmony/destructuring, test/mjsunit/harmony/default-parameters,
test/mjsunit/harmony/default-parameters, test/mjsunit/es6/classes-subclass-builtins,
BUG=

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

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

The CompareICStub produces an untagged raw word value, which has to be
translated to true or false manually in the TurboFan code. But for lazy
bailout after the CompareIC, we immediately go back to fullcodegen or
Ignition with the raw value, to a location where both fullcodegen and
Ignition expect a boolean value, which might crash or in the worst case
(depending on the exact computation inside the CompareIC) could lead to
arbitrary memory access.

Short-term fix is to use the proper runtime functions (unified with the
interpreter now) for comparisons. Next task is to provide optimized
versions of these based on the CodeStubAssembler, which can then be used
via code stubs in TurboFan or directly in handlers in the interpreter.

R=mstarzinger@chromium.org
BUG=v8:4788
LOG=n

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

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

Moves skips to explicit fails and groups errors be failure reason. Almost all failures
are due to lack of generator support.

BUG=v8:4680
LOG=N
TBR=oth@chromium.org

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

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

R=bmeurer@chromium.org
BUG=v8:3956
LOG=n

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

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

This patch adds the newly added support for contexts in V8 Tracing, as well
as use it to mark all the entry points for a V8 Isolate.

Update for reland: The current tracing interface needs to be updated (AddTraceEvent),
but the embedders need to migrate to the new version before removing the old version.
(Reland of: https://codereview.chromium.org/1686233002)

The revert happened because the 2 signatures of the old and new AddTraceEvent where different
so it threw an overload-virtual error on cross arm debug. This issue is temporary, and to solve
it, I added an implementation of the old and new everywhere until the embedder implements the new.

BUG=v8:4565
LOG=N

R=jochen@chromium.org

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

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

Initial commit with the bulk of the src/s390/* changes
along with associated changes to the build toolchain for
the new files.

A minor update to V8PRIuPTR definition for Mac OS X
affecting 32-bit S390 sim compilations.

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

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

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

Port ba2077aa

Original commit message:
Move the already existing fast case for %NewObject into a dedicated
FastNewObjectStub that we can utilize in places where we would otherwise
fallback to %NewObject immediately, which is rather expensive.

Also use FastNewObjectStub as the generic implementation of JSCreate,
which should make constructor inlining based on SharedFunctionInfo (w/o
specializing to a concrete closure) viable soon.

BUG=

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

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

Rebaselines ForOf bytecodes after shipping iterator finalization in https://codereview.chromium.org/1738463003/.

TBR=adamk@chromium.org
BUG=v8:3566,v8:4280
LOG=N

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

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

This fixes the length computation in for object literals in generic
lowering. In rare cases (e.g. boilerplate at end of page) this could
lead to out of bounds reads.

R=bmeurer@chromium.org

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

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

We know it's a postive integer

BUG=
R=bmeurer@chromium.org

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

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

BUG=
R=bmeurer@chromium.org

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

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

The keys are always positive integers, so use an
UnseededNumberDictionary to store them instead of an ObjectHashTable

R=bmeurer@chromium.org

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

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

When operating in --rebaseline mode, each of the files will be updated.
In --raw-js mode, all the expectations will be written to the same file.
In default mode no more than one input file is accepted.

On POSIX systems, --rebaseline will autodiscover golden files when run
from the project root and no input file is provided.

BUG=v8:4280
LOG=N

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

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

R=mstarzinger@chromium.org
BUG=v8:4768
LOG=n

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

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

The LoadBuffer operator that is used for asm.js heap access claims to
return only the appropriate typed array type, but out of bounds access
could make it return undefined. So far we tried to "repair" the graph
later if we see that our assumption was wrong, and for various reasons
that worked for some time. But now that wrong type information that is
propagated earlier is picked up appropriately and thus we generate wrong
code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
thus get 2147483648 instead of 0 (with proper JS truncation).

This was always considered a temporary hack until we have a proper
asm.js pipeline, but since we still run asm.js through the generic
JavaScript pipeline, we have to address this now. Quickfix is to just
bailout from the pipeline when we see that the LoadBuffer type was
wrong, i.e. the result of LoadBuffer is not properly truncated and thus
undefined or NaN would be observable.

R=mstarzinger@chromium.org, jarin@chromium.org
BUG=chromium:589792
LOG=y

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

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