Whenever left-trimming is possible (e.g. whenever user code is
called), we must not store a reference to an exposed JSArray's
elements.
Bug: chromium:897366,v8:7382
Change-Id: I8dd6a93aa6ed19e755ccce7122e0e019dc578a31
Reviewed-on: https://chromium-review.googlesource.com/c/1292066
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56903}
This is to fix test262 tests which expect that there is no arguments
object.
Bug: v8:7186
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56205c29609666dc832297e4d36a4d487eae36cc
Reviewed-on: https://chromium-review.googlesource.com/c/1291469
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56890}
Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.
Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}
In the ElementsAccessor fast-path for Array.prototype.includes, we
iterate backing-store elements according to start and length numbers
which might or might not be within the JSArray::length field, for
example when side-effects changed the receiver while start and length
are computed. So even when we have a packed ElementsKind, we might still
observe the hole. This is fine, since logical out-of-bounds accesses
are safe in this case, but it means we must not rely on the
ElementsKind telling us if we can encounter holes.
Bug: chromium:897098
Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8
Reviewed-on: https://chromium-review.googlesource.com/c/1293571
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56884}
With async_hooks it's also possible that the "current microtask" is an
await task, whose generator is already suspended, when there's an
exception thrown in the AFTER callback. In that case we cannot build
a meaningful async stack trace.
Bug: chromium:897406, v8:7522
Change-Id: I682dc1fc3ebb1864e1c2061041ff99ced0313f0c
Reviewed-on: https://chromium-review.googlesource.com/c/1292057
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56839}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
The original version of this patch had an overly agressive assert that has
been loosened.
TBR=jgruber@chromium.org
Change-Id: I56870862f4b124d1b38372daa326182a526c874c
Reviewed-on: https://chromium-review.googlesource.com/c/1291375
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56829}
This reverts commit 41ba3d3eb0.
Reason for revert: Speculative revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Fuzzer/27370https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20predictable/19895
Original change's description:
> [builtins] Implement Array.prototype.slice in Torque
>
> In the process:
>
> - add volatile types for FastJSArray and remove the length_fast accessor
> from JSArray with the application of more rigorous typing.
> - add micro benchmarks for testing all the interesting slice cases
>
> Also update a few assorted places in .tq code to make them more
> idiomatic.
>
> Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
> Reviewed-on: https://chromium-review.googlesource.com/c/1281603
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56806}
TBR=danno@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I1f2c82b4c3ab0848857f620facacf9604d4fcd11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1290973
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56815}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
Reviewed-on: https://chromium-review.googlesource.com/c/1281603
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56806}
When --async-stack-traces is on and there's an exception from within an
async_hook "after" handler, we will be faced with a settled promise. In
that case we cannot do anything, since the promise will not have any
reactions on it anymore, but we should also not crash of course.
Bug: chromium:896700, v8:7522
Change-Id: I6e3d212d0433da40740489ff7421c5a98cf9bff3
Reviewed-on: https://chromium-review.googlesource.com/c/1290550
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56801}
When creating the buffer for the fall back, the initial entry was not
considered when calculating the size.
Bug: chromium:896181
Change-Id: I7f15bb1bdf31b3255db91b1fe8dcd68c76033980
Reviewed-on: https://chromium-review.googlesource.com/c/1286957
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56768}
Properly handle the case where the CheckFloat64Hole becomes a
no-op after RETYPE (because the feedback type is already Number).
We always need to pass the Number restriction type here.
Bug: chromium:895199
Change-Id: I96a949ba35db1e6d35abedddc4507c101d95b716
Reviewed-on: https://chromium-review.googlesource.com/c/1278804
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56622}
This fixes the typing for the case when the call is not lowered to
the simplified operator.
Bug: chromium:880207
Change-Id: Icecf12de77ece0fe9ffec2777874f5f0004a1e97
Reviewed-on: https://chromium-review.googlesource.com/c/1278642
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56621}
On ia32, we were pinning too many registers, resulting in no unpinned
byte registers left (we only have three byte registers since {ebx}
is reserved for the root register).
It turns out that on most paths, we don't actually need to pin any
registers, since {Store} is often the last call for an operation (like
any store or set_global). If registers need to be pinned, only pass
those that must be kept alive across the {Store}. This allows to
compute a more narrow set of pinned registers on demand inside {Store}.
Plus minor drive-by changes.
R=titzer@chromium.org
Bug: chromium:894374, chromium:894307, v8:6600
Change-Id: Ic4d7131784c193dc7a2abf0e504d9973f6d5c5f1
Reviewed-on: https://chromium-review.googlesource.com/c/1275819
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56587}
Use naming similar to the spec: "table" instead of "function table",
"element segment" instead of "function table init".
Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff
Reviewed-on: https://chromium-review.googlesource.com/c/1273612
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56545}
This reverts commit 471fef0469.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
The RNG state is initialized with random_seed parameter that usually
has lots of zeros. Each random generation iteration shuffles bits with
xor operation over the state. It takes a while before the state is populated
with enough 1s and starts generating uniformly distributed numbers.
The patch warms up the state with 32 iterations when --random_seed is used.
BUG=v8:8265
Change-Id: I7a4e8c842962bea0f2935c7b3673494367d8580f
Reviewed-on: https://chromium-review.googlesource.com/c/1263816
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56418}
For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.
Some drive-by cleanups:
- Remove the switch in NameForRuntimeId() and just use the table of
runtime functions to lookup the name directly.
- Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
they are the last users of the inline versions of these.
- Remove the MaxSmi inline version as it is only used in tests.
Saves 64 KiB binary size.
Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
For --async-stack-traces don't try to peak into frames that don't belong
to async functions/generators, specifically don't try to peak into some
arbitrary builtin frames (the FrameInspector doesn't support that).
Bug: chromium:892472, chromium:892473, v8:7522
Change-Id: Idcdee26ff958c03b24dd2910bb92fc51cbc14e3c
Ref: nodejs/node#11865
Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces
Reviewed-on: https://chromium-review.googlesource.com/c/1264276
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56396}
When converting a Signed32\/MinusZero value from Word32 to Float64
representation or just passing it through as Word32 (with potential
type checks on it) we don't need to worry about -0 as long as the uses
identify 0 and -0.
Drive-by-fix: Fix the CheckChange() helper in the representation
changer test to pass Truncation::Any() by default.
Bug: chromium:891639, chromium:891612, chromium:891627, v8:8015, v8:8178
Change-Id: I06948ec0cdb8e778cb3678124ef927277a5f40ee
Reviewed-on: https://chromium-review.googlesource.com/c/1258902
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56369}
By moving the block range end to left of closing bracket,
we can avoid ambiguity where an open-ended singleton range
could be both interpreted as inside the parent range, or
next to it.
R=verwaest@chromium.org
Bug: v8:8237
Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
Reviewed-on: https://chromium-review.googlesource.com/1254127
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56347}
Delay the creation of FunctionNameVariables until we validated the
FormalParameters. This is needed so we don't declare them in cases where
we later get an error, have to reset, and reparse.
Bug: chromium:890553, v8:7926
Change-Id: I742e6f7f71158e3903843bd583dc7943468c18f6
Reviewed-on: https://chromium-review.googlesource.com/1254061
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#56314}
The representation changer was lacking support for directly converting
Word64 values to Bit representation.
Bug: chromium:890243, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: I5fa31716c7b2b10ad00dc31d5035a1ada152661c
Reviewed-on: https://chromium-review.googlesource.com/1251551
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56304}
- Add a new broker mode kRetired, in which the heap can
again be accessed.
- Change the way modes work. We now always start in kDisabled.
If FLAG_concurrent_compiler_frontend is on, we eventually move
to kSerializing, then to kSerialized, then to kRetired.
- Add an ObjectDataKind to ObjectData that indicates whether the
data is just a dummy (i.e. created while broker was in kDisabled
mode).
This also happens to fix a bug found by clusterfuzz.
Bug: v8:7790, chromium:889722
Change-Id: I38833fe7ad26d2d3efb15ba560576defb82f673a
Reviewed-on: https://chromium-review.googlesource.com/1245425
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56260}
I moved AnalyzePartially from ParseFunctionLiteral to SkipFunction, but arrow
functions only used the ResetAfterPreparsing part.
Bug: chromium:888825
Change-Id: I08de99af128b28031df6ed86a725e4dc918078f8
Reviewed-on: https://chromium-review.googlesource.com/1243383
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56218}
When constructing a TypedArray by length, only actually setup the
JSTypedArray instance once the buffer is allocated, as only at that
time it's known whether the byte length is fine. Otherwise we confuse
the heap verifier.
Bug: chromium:887891
Change-Id: I407ff9a2a053dd11ef764e4e32f482abb27eb0a8
Reviewed-on: https://chromium-review.googlesource.com/1238494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56131}
The order in which ToNumber(left) and ToPrimitive(right,hint Number)
is called when performing an abstract relational comparison is
observable, and we need to make sure to trigger the conversions in
the correct order.
Bug: chromium:687063
Change-Id: Idc9edb99643c4cf1774b89dcdc319ed5dc7cdc8a
Reviewed-on: https://chromium-review.googlesource.com/1236557
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56125}
Previously we only supported strings and not filenames. This
changes the default to filename and adds a new `type: string` which can
be passed `options` to allow for strings to be passed in test code.
See: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker
Bug: v8:8020
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie8818885c5c5c071b6614852322cb45aeb01a647
Reviewed-on: https://chromium-review.googlesource.com/1185980
Commit-Queue: Sam Clegg <sbc@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56056}
The JSTypedArray instance is created early on in the TypedArray
constructors, using EmitFastNewObject, which puts Undefined into
all slots. But the code might still produce an exception afterwards
leaving the JSTypedArray in a weird state. It's not a security issue
since the object doesn't escape, but it confuses the heap verifier.
Bug: chromium:885404, v8:4153, v8:7881, v8:8171
Change-Id: I5fb8131fcae69edf4a92602ed477dca305c3d6c7
Reviewed-on: https://chromium-review.googlesource.com/1233257
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56019}
This is the next step to support large array buffers. On 64-bit archs
the full safe integer range is available (up to 2^53-1 bytes in theory).
On 32-bit platforms the full Unsigned31 range is allowed, so that we can
continue to use CheckBounds for typed arrays and data views in the
optimizing compiler (it's generally unlikely that the kernel will give
you more than 1GiB of contiguous memory anyways).
Drive-by-fix: This introduces proper chokepoints for the byte_offset
and byte_length accesses in the CSA code, and also does some renaming
for consistency.
Bug: v8:4153, v8:7881, v8:8171
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I92a767638532ca9f86084398ce72556c5180cc6e
Reviewed-on: https://chromium-review.googlesource.com/1228377
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56008}
Word8 and Word16 representation is treated like Word32 for the sake of
TurboFan's representation selection, but this was missing from the
Word64 conversions.
Bug: chromium:884933, v8:4153, v8:7881, v8:8171, v8:8178
Change-Id: If7b69cdd02b12546d87bba0643e9ee9cb35cb299
Reviewed-on: https://chromium-review.googlesource.com/1229953
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55983}
This verifies that asm.js over the internal parameter count limit
does not crash. The internal limit is 1000 parameters, and the test
was using >3000 parameters. Reduce this down to 1005, and also
introduce a test which does not dynamically construct the string
and eval it, because the construction of this string takes time.
Mark the old test as slow in debug mode.
R=machenbach@chromium.org
BUG=v8:8165
Change-Id: Ib6ef5e1e58d3f37a71720fb59afa19464e7f2ff7
Reviewed-on: https://chromium-review.googlesource.com/1224057
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55860}
This is an unmodified reland of ece86adc6b.
Original change's description:
> [typedarray] Properly convert hole to undefined in TypedArray.from
>
> It used to call the old IterableToList, which had the wrong
> semantics for holes.
>
> Bug: v8:8133
> Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
> Reviewed-on: https://chromium-review.googlesource.com/1213204
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55745}
Tbr: petermarshall@chromium.org
Bug: v8:8133
Change-Id: I91c1eaf61cbcc29116e3a6cc3415f29cfba3561e
Reviewed-on: https://chromium-review.googlesource.com/1223007
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55846}
This reverts commit ece86adc6b.
Reason for revert: Potential cause of auto-roller breakage https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win10_chromium_x64_rel_ng/91864
Original change's description:
> [typedarray] Properly convert hole to undefined in TypedArray.from
>
> It used to call the old IterableToList, which had the wrong
> semantics for holes.
>
> Bug: v8:8133
> Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
> Reviewed-on: https://chromium-review.googlesource.com/1213204
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#55745}
TBR=neis@chromium.org,petermarshall@chromium.org,dhai@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8133
Change-Id: I09b108e7844c598253fbbe02d705699c21308637
Reviewed-on: https://chromium-review.googlesource.com/1220286
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55802}
This CL fixes a bug that allowed calls to Array.p.shift on
zero-length arrays where the 'length' is read-only without throwing
a TypeError.
R=bmeurer@chromium.org, jgruber@chromium.org
Bug: chromium:882233
Change-Id: Ib129ab4c4f4f233e7bb553effa77539badfbe26e
Reviewed-on: https://chromium-review.googlesource.com/1215164
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55746}
It used to call the old IterableToList, which had the wrong
semantics for holes.
Bug: v8:8133
Change-Id: Idd5acd55a155bc43df7552135a44151bb2db38e9
Reviewed-on: https://chromium-review.googlesource.com/1213204
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55745}
This CL implements a generic baseline version of Array.p.unshift
in Torque, enabling us to remove the JS fall-back.
The elements-accessor fast-path is still used, but the check whether
to use it is also moved to Torque.
Support for sparse JSArrays is removed.
Drive-by change: Small refactoring in builtins-array that will
get extended to other array builtins in a follow-up CL.
R=cbruni@chromium.org, jgruber@chromium.org
Bug: v8:7624
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7b23ce15e7b922eb333f61a408050dedec77c95a
Reviewed-on: https://chromium-review.googlesource.com/1189902
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@{#55670}
The Math.expm1() function can actually return -0, for example in the
case that -0 is passed to it.
Bug: chromium:880207
Change-Id: If3a7a3a1fb6a18075ba0d7816687dfd831ebe293
Reviewed-on: https://chromium-review.googlesource.com/1205072
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55657}
Before, splice was implemented with a C++ fast path and a
comprehensive JavaScript version.
This impl. is entirely in Torque with a fastpath for SMI,
DOUBLE and OBJECT arrays, and a comprehensive slow path.
The same level of "sparse" array support as given by the
array.js implementation is included.
This reland addresses several issues:
* Removed "sparse" array support from splice.
* Addressed ClusterFuzz issue 876443:
The test and code that uses the fix is in this CL.
The fix in isolation can be seen here:
https://chromium-review.googlesource.com/c/v8/v8/+/1199403
* Removed dead code in elements.cc
BUG=chromium:876443, v8:8131, v8:1956, v8:7221
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I2d4a66c24ba1edabeca34e27e6ff8ee6136ed5f1
Reviewed-on: https://chromium-review.googlesource.com/1201783
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55610}
This fixes exception creation (by the WebAssembly throw operation) so
that it is not observable by JavaScript. Internal properties are now
stored with symbol names instead of string names, which also prevents
them from being accessed or monkey-patched directly by JavaScript.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-8094
BUG=v8:8094
Change-Id: I33cb27f4373114cd4db28d9aef23560093e55242
Reviewed-on: https://chromium-review.googlesource.com/1203951
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55602}
The previous typing rules for ToNumeric and ToNumber didn't match on the
NonBigIntPrimitive input set, which causes trouble when we morph ToNumeric
nodes into ToNumber nodes, and generally lead to worse typings in the
graph, and thus worse code generation. This change improves the existing
typing rules and turns ToNumber into a chokepoint again.
Bug: chromium:879898, v8:8015
Change-Id: I4a7ff0e9c420c5dcfdb2b96884e019a5943828a4
Reviewed-on: https://chromium-review.googlesource.com/1201522
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55595}
This CL fixes an issue where getters/setters would get called on a
prototype with the wrong receiver. This happens in the pre-processing
for Array.p.sort when values get copied down from the prototype chain.
R=jgruber@chromium.org
Bug: v8:7682
Change-Id: I0d8ff1dc721c33bd721aaca54ffd357b3d2a2096
Reviewed-on: https://chromium-review.googlesource.com/1198767
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55546}
This CL removes a regression test that was intended to check that the
maximum call stack size was not exceeded when calling Array.p.sort.
As the new sorting algorithm (TimSort) does not work recursively, this
test is no longer really necessary. It is also rather slow and causes
issues on some bots, so we remove the test.
R=mslekova@chromium.org
Bug: v8:7783
Change-Id: I5bb9693ab825fe077776fd6825688545286285fd
Reviewed-on: https://chromium-review.googlesource.com/1196511
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55527}
This CL fixes a bug if the second argument ('from') for lastIndexOf
changes the array when its converted to an integer.
R=jgruber@chromium.org
Bug: chromium:878845
Change-Id: I8759dd19381c63f0dde1d4c5abc1b6c7291c6048
Reviewed-on: https://chromium-review.googlesource.com/1196507
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@google.com>
Cr-Commit-Position: refs/heads/master@{#55525}
This fixes a crash with a predicate used during stack unwinding of
WebAssembly frames during exception handling. The predicate caused an
observable side-effect in JavaScript during unwinding, code that is
inherently unhandlified and is not allowed to be observable.
The fix actually just removes the entire predicate. This is because the
updated proposal causes all JavaScript exceptions to participate in
WebAssembly exception handling, allowing modelling of "finally" language
constructs to perform cleanup independent of the embedders exception
details.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-8095
BUG=v8:8095
Change-Id: Ic03bc45e7b7f4562a431ccf910ee9ddcf558aa48
Reviewed-on: https://chromium-review.googlesource.com/1193445
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55457}
This method introduces an inherent race because it allows changing
global static flag variables from concurrently running Isolates (or
Workers). Since there are not too many use-cases left, the method in
question can be removed entirely.
R=hpayer@chromium.org
Change-Id: I9798730dd775b04f0bc83f18ed5982672e76e5d5
Reviewed-on: https://chromium-review.googlesource.com/1186731
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55392}
This CL adds a baseline implementation for Array.p.reverse in Torque,
as well as fastpaths for PACKED elements kinds.
Support for sparse JSArrays was removed.
R=jgruber@chromium.org, petermarshall@chromium.org
Bug: v8:7624
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I12900fbbb44746f1c5d36b78be826e14b88b4f69
Reviewed-on: https://chromium-review.googlesource.com/1185600
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55369}
Instead of changing the [[IteratedObject]] field to undefined to mark an
array iterator as exhausted, store the appropriate maximum value into
the [[ArrayIteratorNextIndex]] field such that the iterator will never
produce any values again.
Without this change the map check and the "length" access on the
[[IteratedObject]] cannot be eliminated inside the loop, since the
object can either be the array or undefined. Even with this change
it's still not possible immediately due to missing aliasing
information in the LoadElimination, but it paves the way for follow
up improvements. Eventually the goal is to have `for..of` as fast as
a traditional `for` loop even for really tight loops.
This CL also hardens the implementation of the ArrayIterator by using
proper CASTs and CSA_ASSERTs. The readability of the CSA builtin was
improved by utilizing proper helper functions.
Bug: v8:7510, v8:7514, v8:8070
Change-Id: Ib46604fadad1a0f80e77fe71a1f47b0ca31ab841
Reviewed-on: https://chromium-review.googlesource.com/1181902
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55261}
The RegExp replace implementation is a bit of a mess. Here, we first
try to handle parts of RegExp.p.exec, and then call directly into the
raw irregexp code (skipping RegExp.p.exec).
We got parts of this wrong: when lastIndex > string.length and the
regexp instance is sticky, two things should happen. 1. The match
should fail, and 2. lastIndex should be reset to 0. On the fast path,
we did the latter but not the former, instead running exec with a
lastIndex of 0.
This CL omits the irregexp call in this case, and defaults to a failed
match instead.
Bug: chromium:875493
Change-Id: I8c959610d267575e37686076a3fd5dfde322f0ca
Reviewed-on: https://chromium-review.googlesource.com/1180889
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55207}
This makes sure the aforementioned predicate is independent of the
current context (aka. Realm) and only uses the instance type of the
given object to determine whether it is a WebAssembly module object.
R=titzer@chromium.org
TEST=mjsunit/regress/wasm/regress-8059
BUG=v8:8059
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Icc8e400f8412483f2a3883ca65c58b7ef938ef23
Reviewed-on: https://chromium-review.googlesource.com/1180886
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55205}
Enforce both engine limitations and spec (http://asmjs.org/spec/latest/)
limitations on the size of asm.js heaps.
R=clemensh@chromium.org
CC=mstarzinger@chromium.org
Bug: chromium:873600
Change-Id: I104c23bbd0a9a7c494f97f8f9e83ac5a37496dfd
Reviewed-on: https://chromium-review.googlesource.com/1174411
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55163}
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}
Byte offset can be outside of Smi range and must be loaded as a Number
rather than a Smi.
Bug: chromium:852258
Change-Id: Ida6e07ba68a050d4f5a9f28500986cc67c619b4c
Reviewed-on: https://chromium-review.googlesource.com/1100886
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53748}
`date` could be outside the int32_t range and thus FastD2I may not be
used.
Bug: chromium:849663
Change-Id: I96a012b40d35ec8f80e449e4e687b0ce7b572d5e
Reviewed-on: https://chromium-review.googlesource.com/1087063
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53526}
Compress the parameter count (and function length) stored in
SharedFunctionInfo to a uint16_t. This limits us to 2^16 - 1 parameters
per function, minus one for the "don't adapt arguments" sentinel value,
which is one fewer than Code::kMaxArguments was already. Anyway, 65534
arguments should be enough for anyone!
This drops SFI size by 4 bytes.
Bug: chromium:818642
Change-Id: I126bfb24453dcdc5087a104d3a12cf195a56fa9f
Reviewed-on: https://chromium-review.googlesource.com/1076627
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53447}
The regression test 2185-2 measured the Array.p.sort time for various
pre-sorted data configurations. This CL adds the various data
configurations to the ArraySortPreSorted benchmark and removes the
regression test altogether.
R=cbruni@chromium.org, jgruber@chromium.org
Change-Id: I6e2eb235e4a7578f4a107229bfc6a9e89a3aa5e3
Reviewed-on: https://chromium-review.googlesource.com/1076188
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@{#53420}
This loads references to {null} values from the instance object instead
of embedding them into the generated code. It is one step towards making
the {WasmCode} objects independent of the Isolate.
Note that this also fixes an issue with the serializer/deserializer that
failed to properly serialize {null} values and accidentally collapsed
them to {undefined} values instead.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-7785
BUG=v8:7424,v8:7785
Change-Id: Ie436c2d96890e7c8c89ffe2bd4189a759254775b
Reviewed-on: https://chromium-review.googlesource.com/1070981
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53352}
At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.
R=mstarzinger@chromium.org
Bug: chromium:837417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
Instead use the canonical empty fixed array. Some code assumes
that this is the only fixed array of length 0.
Bug: chromium:843062
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: If780acf50147c061a81f2ff2b31779fbd1c78559
Reviewed-on: https://chromium-review.googlesource.com/1064052
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53320}
This is not web compatible, so let's delete the code.
Bug: v8:5536
Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e
Reviewed-on: https://chromium-review.googlesource.com/1064740
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53264}
The js-to-wasm wrappers are shared across instances, so we cannot
directly call the instance-specific wasm-to-js wrappers. Instead, we
need to call via the import table.
R=titzer@chromium.org
Bug: chromium:843563
Change-Id: Ia882604f6769472fe2eb69176cbed728215ced29
Reviewed-on: https://chromium-review.googlesource.com/1064610
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53254}
It is possible for user code to modify fast regexp result objects
before they are used e.g. by RegExp.p.match, so we may not make any
assumptions about their contents. The only exception is when the
RegExp itself is fast.
Bug: chromium:843022
Change-Id: I14eafbdfb2b2ced609da1391b57c73cbe167f7fb
Reviewed-on: https://chromium-review.googlesource.com/1061455
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53210}
Array.indexOf accepts an optional fromIndex argument. When non-negative,
this argument restricts the searched indices to those starting at
fromIndex:
[1, 2, 1].indexOf(1,1) == 2
When negative, it is meant to be added to the array length to provide
such initial index for the search:
[1, 2, 1].indexOf(1, -2) == 2
This transformation has been done by the non-optimised builtin but not
by the reducer. The CL adds this construction to the reducer.
Bug: chromium:842612
Change-Id: I0ff089997f4ebb4dc3c2923e52c382a8a96cd711
Reviewed-on: https://chromium-review.googlesource.com/1059628
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53197}
The clusterfuzz issue crashes because VisitBinops expected only but 4
input operands but in the generated graph 5 input operands get created
The issue is fixed by increasing the size of the input operand buffer.
R=jarin@chromium.org
Bug: chromium:842501
Change-Id: I4bbb09a968e165e6f5a0a02d06eee97333f7aa38
Reviewed-on: https://chromium-review.googlesource.com/1056989
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53147}
We must not accept something of kBit representation as of
kWord32 representation (unless it's truncated accordingly).
Deopt instead.
Bug: v8:7740
Change-Id: Ib4f73600d66f8762a6e22f7ea1ce79e8ef451b34
Reviewed-on: https://chromium-review.googlesource.com/1054670
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53144}
This was already the case for 1-byte strings. This prevents crashes when
attempting to externalize such strings.
Bug: chromium:842078, v8:7464
Change-Id: I3092a6748edaf77b2689f7b6f6b949929998e508
Reviewed-on: https://chromium-review.googlesource.com/1054290
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53124}
Avoid writing NumberOfElements to HashTable when it hasn't changed as
the HashTable could be in RO_SPACE and this operation will crash.
Bug: v8:841592
Change-Id: Iffadd567fc10aa9cd13d953da81275464b16c6c0
Reviewed-on: https://chromium-review.googlesource.com/1052693
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53116}
This is a reland of e084eea628.
Undefined behavious was fixed in https://crrev.com/c/1051235.
Original change's description:
> Fix SourcePositionInfo for wasm
>
> In wasm we often don't have a SharedFunctionInfo associated with a
> compilation job, so we can't get a Script. Just print "unknown" in
> these cases (instead of crashing).
>
> R=titzer@chromium.org
> CC=herhut@chromium.org
>
> Bug: chromium:840757, v8:7738
> Change-Id: I850c6adfd9e07c9a0f6dd018f1a9314feb89d887
> Reviewed-on: https://chromium-review.googlesource.com/1049632
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53080}
TBR=titzer@chromium.org
Bug: chromium:840757, v8:7738
Change-Id: If04040a33766955cfed78e7c27226dd04c3f9b9f
Reviewed-on: https://chromium-review.googlesource.com/1051266
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53111}
