In order to know which labels are valid continue targets, we must
track the labels that immediately prefix an iteration statement.
Also document some things that I had to figure out.
Bug: v8:8033
Change-Id: Ia8288fd0e553a547aa0f9d1b4381bb103325bc3a
Reviewed-on: https://chromium-review.googlesource.com/1172292
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55110}
This is a reland of a4355b77b3
Original change's description:
> [test] Add files not pushed for test on Android
>
> TBR=neis@chromium.org
> NOTRY=true
>
> Bug: v8:8047
> Change-Id: I6d59cd9137f56a5061d836afb02b33f7b25d4aa0
> Reviewed-on: https://chromium-review.googlesource.com/1170772
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55047}
TBR=neis@chromium.org
NOTRY=true
Bug: v8:8047
Change-Id: If273d9407ed17f4de827b08039efe4d5cd34632e
Reviewed-on: https://chromium-review.googlesource.com/1171282
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55063}
This CL fixes a bug found by Clusterfuzz, in which the functions
LoadDataViewByteOffset and -ByteLength incorrectly had a return
type of TNode<Smi> instead of TNode<Number>.
This caused a CAST() call to fail when the requested byte offset
or byte length did not fit inside a Smi, i.e. when the underlying
ArrayBuffer of the DataView had a length longer than 2^30 on
32-bit platforms.
The CL also includes a new test in mjsunit to test against this.
Bug: chromium:869313
Change-Id: Ibb7d29bda5782a12c4b506c070bb03fef8c3ec70
Reviewed-on: https://chromium-review.googlesource.com/1158582
Commit-Queue: Théotime Grohens <theotime@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54900}
While working on crrev.com/c/1141045 I caused 3 assertThrows() tests
under the 'Deeply nested target' tests to fail. The tests for
defineProperty, isExtensible, and preventExtensions began to fail under
a couple build configurations because my change modified the stack check
code such that it no longer inhibited tail call optimization. Under some
build configurations the methods responsible for causing a stack oveflow
for those 3 methods were tail call optimized and the tests no longer
threw an exception.
Other built-in implementations of proxy handler methods could also fail
in the future due to refactors moving variables off the stack. Change
the test to ensure v8 doesn't crash but don't rely on stack overflow
exceptions being thrown for the 'deeply nested target' test.
BUG=chromium:864705
Change-Id: Iefeaa1d5402986c1831d0f259f83025452756387
Reviewed-on: https://chromium-review.googlesource.com/1159356
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54878}
The original implementation of 'testAsync' in mjsunit.js required to
put the call to '%AbortJS' into an 'eval' statement. The reason is that
this call requires the flag --allow-natives-syntax to be set, but the
flag is not set in all mjsunit tests. With the use of 'eval'
compilation errors can be avoided.
The problem with this approach was that the fuzzer started to produce
test cases which include the line 'eval("%AbortJS(message)");', and
this line crashes intentionally. Different to the line
'%Abort(message)', however, the 'eval' statement cannot be filtered
so easily in the fuzzer. Therefore I pulled the implementation of
'testAsync' into a separate file to avoid the 'eval'.
Additional changes: I use '===' now instead of 'deepEquals' in
AsyncAssertion.equals because 'deepEquals' is not available outside
mjsunit.js. Using '===' seems more appropriate anyways because for
all tests but one it is sufficient, and it is more precise than
deepEquals.
R=gsathya@chromium.org
Bug: chromium:774841
Change-Id: I47270aa63ff5a1d6aa76a771f9276eaaf579c5ac
Reviewed-on: https://chromium-review.googlesource.com/1156598
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54833}
The ToBigInt conversion can have side effects, so the check for
neutered-ness must happen afterwards.
Bug: chromium:867776
Change-Id: I6e550c77a284da4cf132c21a6c3b1ed8f34eedc9
Reviewed-on: https://chromium-review.googlesource.com/1153553
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54761}
The CSA fast path returned null for Proxy.prototype whereas runtime GetProperty
returned undefined. The CL fixes this discrepancy by returning undefined for
both cases and this makes it complaint with the spec.
Change-Id: I35b75c09dc99e8fd629671e30eacd2cabea8c1d4
Reviewed-on: https://chromium-review.googlesource.com/1145438
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#54745}
If an exception is thrown in instrumented async code, for instance
await import('non-existing-module')
it should be correctly reported by the hooks that run around this code.
Also calling ToLocalChecked() on the hook result is wrong if the hook
has thrown an exception.
Bug: chromium:865892
Change-Id: I5712376fe4426a3e49223d821e4647150887a258
Reviewed-on: https://chromium-review.googlesource.com/1146561
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54610}
This is a reland of 9eca23e9ed
Adds a deopt continuation, which fixes JavaScript stack traces
to contain the number constructor after inlining.
Original change's description:
> [turbofan] Inline Number constructor in certain cases
>
> This CL adds inlining for the Number constructor if new.target is not
> present. The lowering is BigInt compatible, i.e. it converts BigInts to
> numbers.
>
> Bug: v8:7904
> Change-Id: If03b9f872d82e50b6ded7709069181c33dc44e82
> Reviewed-on: https://chromium-review.googlesource.com/1118557
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54454}
Bug: v8:7904
Change-Id: Ic416e5ba81fa3a0f59ae4afa80df83c46a759487
Reviewed-on: https://chromium-review.googlesource.com/1146581
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54609}
This CL changes Array.p.fill to use the baseline implementation
for everything other than JSArray.
One of the reasons is that shadowing the length property on
TypedArrays (and other ElementsKinds) is allowed and should be
respected by Array.p.fill. The fast-path for fill for TypedArrays
expects the indices to be clamped to the actual length of the
underlying backing store and not to some length property.
While this mismatch (and others) could probably be handled properly,
we do the conservative thing and only use the fast-path for specific
JSArrays.
R=jgruber@chromium.org
Bug: chromium:865312
Change-Id: Ib3050e3bfc22d47ca8597b6df34788dc2b59b6e1
Reviewed-on: https://chromium-review.googlesource.com/1142772
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#54558}
i32 stack parameters can be loaded by Turbofan as 64-bit value, hence
they would not be zero extended. If this loaded value is then passed to
Liftoff (which assumes zero-extended i32 values), we could use it for
memory accesses, which would be out of bounds.
R=mstarzinger@chromium.org
Bug: chromium:864509, v8:6600
Change-Id: I0f45a269b1fb1c2befc2e6bc660c559a88323767
Reviewed-on: https://chromium-review.googlesource.com/1140168
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54500}
The instruction selector currently sometimes emits a lea32 with an
offset of 0, which the code generator just ignores (emits no code at
all). This can result in the result of TruncateInt64ToInt32 to not be
zero extended.
This CL fixes that by disallowing lea32 instructions with 0 offset, and
fixing the instruction selector to generate a movl or just no code for
that case.
R=jarin@chromium.org
Bug: chromium:863810, v8:7947
Change-Id: I1b21fc5f0fda9ca3144917538c3d0bbf46601c33
Reviewed-on: https://chromium-review.googlesource.com/1137825
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54489}
This removes an occurrence where the "%Foo" native syntax appears as part
of a string. Such strings are picked up by the fuzzer and recombined in
unsupported ways, producing false-positive crash reports. Simply avoid
having those strings in the fuzzing corpus.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-808848
BUG=chromium:844842
Change-Id: I017c1552578f0d26033e58b11353e87e27a69ebf
Reviewed-on: https://chromium-review.googlesource.com/1136300
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54432}
When we changed FeedbackMetadata to be it's own type instead of a
subtype of FixedArray, we missed this check for valid objects in old
space. This restores the old behavior during verification.
Bug: chromium:862433
Change-Id: Icdb144df4aebc0c6d78a28405c7f53e40b2e1376
Reviewed-on: https://chromium-review.googlesource.com/1134995
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54408}
After liveedit removed - we do not need this context any more.
R=yangguo@chromium.orgTBR=clemensh@chromium.org
Bug: v8:5530
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Idb43d016d51b8048f6cd2ca590fd7510abcacb49
Reviewed-on: https://chromium-review.googlesource.com/1106802
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54273}
Fixes V8 correctness failure when there's a proxy in the global object
prototype chain and unsuccessful attempt is made to access a property.
Bug: chromium:849024
Change-Id: I829e1a6c038982b7c7a77f8bdefb61facb4614f0
Reviewed-on: https://chromium-review.googlesource.com/1124446
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54237}
We need to push the sign-extended constant instead of just the lower 32
bits. Otherwise, the callee might read stale data from the stack.
Bug: chromium:854011, v8:6600
R=ahaas@chromium.orgCC=rodolph.perfetta@arm.com
Change-Id: Iafcfd6ba9532771615b41215fb4d1a2b85ce5623
Reviewed-on: https://chromium-review.googlesource.com/1124683
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54185}
This CL adds a regression test that will check that the elements
pointer is properly reloaded after the JavaScript comparison
function is called during Array.p.sort.
R=jgruber@chromium.org
Bug: chromium:859809
Change-Id: I15f55fcc1906bd8d0751596e5457367a643b92da
Reviewed-on: https://chromium-review.googlesource.com/1124475
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54174}
This CL changes the NumberDictionary fast-path for Array.p.sort to
throw a TypeError when trying to write to a read-only property.
Previously, the fast-path simply bailed to the slow-path which could
swallow the TypeError by accident. I.e. because the fast-path could
leave the array in an inconsistent state that is already sorted.
Example:
let arr = new Array(10);
Object.defineProperty(arr, 0, {value: 2, writable: false});
Object.defineProperty(arr, 2, {value: 1, writable: false});
arr.sort();
The pre-processing step will move the value 1 to index 1: {0: 2, 1: 1}
When trying to swap those 2 values, the fast-path will write the 2 at
index 1, then try to write the 1 at index 0 and fail, bailing to the
slow-path. As the array looks like {0: 2, 1: 2} its already sorted
and the TypeError will not be thrown.
R=jgruber@chromium.org
Bug: v8:7382, v8:7907
Change-Id: I5d2f2d73478fdca066ce1048dcb2b8301751cb1f
Reviewed-on: https://chromium-review.googlesource.com/1122120
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54150}
For spread calls with arrays with double elements but zero length,
we skip the box-as-heapnumber step; so in this corner case the
Call builtin sees a FixedDoubleArray, which is fine because it
doesn't read any of the raw double values from it.
This patch doesn't change the implementation, it only updates the
assert to match reality.
Bug: chromium:856095
Change-Id: I0227f4ccbc6c61c8f5f7669a266ef7a64c6a9a43
Reviewed-on: https://chromium-review.googlesource.com/1117922
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54149}
When parsing a numeric literal in a line like "a=0x0e+b|0;",
currently the scanner consumes the "e+" part (as it thinks
it's the start of an exponent).
In the ECMAScript lexical grammar HexIntegerLiteral cannot
contain exponents, which means the '+' character should be
parsed as a binary operator.
R=bradnelson@chromium.org
BUG=v8:7893
Change-Id: I97a0d4ea2ee1d38a3462efbfaef5eb87b8ea704b
Reviewed-on: https://chromium-review.googlesource.com/1116551
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54132}
This CL fixes the NumberDictionary fast-path in Array.p.sort, when
storing to a read-only property that was never read from.
R=jgruber@chromium.org
Bug: v8:7907
Change-Id: I2b772fb5b1619a94a7d239ba4417ecb7902a167c
Reviewed-on: https://chromium-review.googlesource.com/1119910
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54109}
This is a reland of ada648006b, fixed
for 32 bit architectures (register pairs).
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: Ibc8801737e9604a8490382c569b0378585625376
Reviewed-on: https://chromium-review.googlesource.com/1112238
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53981}
This reverts commit ada648006b.
Reason for revert: Failure with slow dchecks: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/20982
Original change's description:
> [Liftoff] Fix register use count
>
> In {SetLocalFromStackSlot}, we decrement the use count of the register
> in the target slot without updating this slot, and then call
> {GetUnusedRegister}. At that point, the register use counts do not
> match the cache state, which leads to errors later on.
> This CL fixes this by marking the target slot as a stack slot after
> reducing the register use count.
>
> It also adds a Validation which helped to find that error and will
> catch similar errors earlier.
>
> R=titzer@chromium.org
>
> Bug: chromium:854050, v8:6600
> Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
> Reviewed-on: https://chromium-review.googlesource.com/1111958
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53976}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: I5b8d8d405dcd7f82ee431cba290419425b9859a1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:854050, v8:6600
Reviewed-on: https://chromium-review.googlesource.com/1112277
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53979}
In {SetLocalFromStackSlot}, we decrement the use count of the register
in the target slot without updating this slot, and then call
{GetUnusedRegister}. At that point, the register use counts do not
match the cache state, which leads to errors later on.
This CL fixes this by marking the target slot as a stack slot after
reducing the register use count.
It also adds a Validation which helped to find that error and will
catch similar errors earlier.
R=titzer@chromium.org
Bug: chromium:854050, v8:6600
Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
Reviewed-on: https://chromium-review.googlesource.com/1111958
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53976}
Cleanup decoding of flags so that invalid flags for sections other than
memory are caught correctly.
Bug: chromium:853453
Change-Id: Ia347d5f7672eee93ca3f6a743f06fba629f55cb5
Reviewed-on: https://chromium-review.googlesource.com/1104976
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53972}
This CL fixes a bug where execution would continue on a fast-path
even though a previous recursion step bailed to the slow path. This
would allow possibly illegal loads that could leak to JS.
Drive-by change: Instead of bailing to the slow-path on each recursion
step, we now bail completely and start the slow-path afterwards.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: chromium:854299, v8:7382
Change-Id: Ib2fd5d85dbd0c3894d7775c4f62e053c31b5e5d1
Reviewed-on: https://chromium-review.googlesource.com/1107702
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53892}
This CL fixes a bug that allowed OOB read/stores on fastpaths when
a comparison function caused the underlying FixedArray to change
while keeping the elements kinds and size property on the original
JSArray the same.
R=jgruber@chromium.org
Bug: chromium:852592
Change-Id: I09af357d10e7f41e75241e4c87430fc9aa806f8c
Reviewed-on: https://chromium-review.googlesource.com/1104158
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53811}
Reading up on the bug description, this is a test
that is triggered by TurboFan execution. This can
be done with natives and does not need excessive
loop iterations. Additionally, we have a more specific
regression test for the original issue in the repo:
http://crrev.com/c/584837
Bug: v8:7783
Change-Id: Id022b515b663e6fb897acb29f43ef92b70b547b8
Reviewed-on: https://chromium-review.googlesource.com/1101018
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53799}
