Remove the {ErrorThrower} parameter to {CallWasmFunctionForTesting} (it
was only populated in a subset of failures anyway), and merge it with
{RunWasmModuleForTesting}.
R=ahaas@chromium.org
Bug: chromium:1113681
Change-Id: I5391e2f911928641a907bc5dad5a54677c90acb6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346279
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69327}
This CL adds more systematic predicates to JSFunction to reason about
available code kinds. Introduced terminology:
- Attached code kinds are accessible directly from the JSFunction
itself.
- Available code kinds are either attached or accessible indirectly.
- The Active code kind is the one that would be executed on the next
function execution.
Bug: v8:8888
Change-Id: I9468884dfe97a6cb73f8329b2b6cb62b622d3e7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345966
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69325}
The "wasm fuzzer" and "wasm async fuzzer" use the
{InterpretAndExecuteModule} function, which did not check for possible
nondeterminism in the interpreter yet. This can lead to wrong reports
of mismatches, or in endless loops being executed in compiled code which
was not executed in the interpreter.
This CL adds the check for nondeterminism in that function, and adds a
TODO to merge the two very similar methods.
R=ahaas@chromium.org
Bug: chromium:1112099, chromium:1113681
Change-Id: I80b01d4c53d04f0632807fa852147dc9fb8075ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346280
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69324}
The interpreter is used for testing (including fuzzing) only, and in
these cases it's often important to see the exact value of a float. Both
decimal and scientific notation does not show the full value though, and
decimal representation can also be really long for large values, making
it hard to compare values.
This CL switches this debug output to hexadecimal float values, which
always shows the float value in full precision and is also much shorter
than decimal notation in many cases.
R=ahaas@chromium.org
Bug: chromium:1112099
Change-Id: Ia84824227fcd2f1e763ab89280a202ed44930a71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346646
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69323}
32-bit MSVC generates a C4018 warning for signed/unsigned mismatch.
Fix this by casting the std::numeric_limits<int32_t>::max() return
value.
Change-Id: Iaff6b81c797a88654a7d2fa6d910da105d824df8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346934
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69321}
The design included per-location lists, but they were left out in
Version 1 of the implementation.
In addition: drive-by style unification.
Bug: v8:10239
Change-Id: Ia4d69fdf4ce0c3aad2dae8082e00e9fa14c4170a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339620
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69319}
The hight 32 bits of the result of mulhw are undefined and need
to be cleared manually.
Change-Id: I0e746898aa26a7970ab59b89c374afd1377028ea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347208
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69318}
This reverts commit 57242a051e.
Reason for revert: regression tests fails:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/31477
Original change's description:
> [wasm-simd][arm] Use vmov to move all ones to register
>
> vceq(dst, dst, dst) does not seem to always set the register to all
> ones. The right way should be be to use vmov (immediate) anyway. This
> was not supported in the assembler yet, so we need changes to the
> assembler, diassembler, and simulator.
>
> There is an unfortunate fork in logic in the simulator, due to the way
> the switches are set up, vmov (imm) logic is duplicated across two
> different cases, because the switch looks at the top bit of the
> immediate. Refactoring this will be a bigger change that is irrelevant
> for this bug, so I'm putting that off for now. Instead we extract the
> core of vmov (imm) into helpers and call it in the two cases.
>
> Bug: chromium:1112124
> Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
> Commit-Queue: Zhi An Ng <zhin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69315}
TBR=bbudge@chromium.org,jkummerow@chromium.org,v8-arm-ports@googlegroups.com,zhin@chromium.org
Change-Id: I5d9d1dcb81771f71001d959ec5a03a43a11c4233
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1112124
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2347211
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69316}
vceq(dst, dst, dst) does not seem to always set the register to all
ones. The right way should be be to use vmov (immediate) anyway. This
was not supported in the assembler yet, so we need changes to the
assembler, diassembler, and simulator.
There is an unfortunate fork in logic in the simulator, due to the way
the switches are set up, vmov (imm) logic is duplicated across two
different cases, because the switch looks at the top bit of the
immediate. Refactoring this will be a bigger change that is irrelevant
for this bug, so I'm putting that off for now. Instead we extract the
core of vmov (imm) into helpers and call it in the two cases.
Bug: chromium:1112124
Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69315}
Optimize shuffles which only use a single operand (called swizzles),
after canonicalization.
Bug: v8:10696
Change-Id: I2e5ffdb723123dffb0abcb6126345972ddc9f652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335735
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69313}
With a displacement of int32_t min (-2^31), and a displacement mode of
kNegativeDisplacement, we will try to negate this constant, but the
result will not fit in an int32_t, leading to a runtime crash.
Check for this special case in CanBeImmediate, and return false.
Bug: chromium:1091892
Change-Id: I7f18153d13805f2836dd5c8e1bc098f1e9600566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341095
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69311}
The plain "wasm fuzzer" (which takes the fuzzer input as the wasm wire
bytes) was already running both the interpreter and compiled code, but
it did not compare the results of both.
This CL fixes this by reusing some logic that was already present in the
fuzzers based on the {WasmCompileFuzzer} class.
R=ahaas@chromium.org
Bug: chromium:1113681, chromium:1112099
Change-Id: I9d407f66dfcba0eec90f050630b028edd5fae1d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339624
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69310}
Add missing source position for stack check, used by OSR to find the
correct return address.
R=clemensb@chromium.org
Bug: v8:10235
Change-Id: Ie26dd3b2079168e846f84b3a4ffe18b838649be7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339625
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69309}
We consider some function "test-only" function, e.g. if they have a
"ForTesting" in their name. The src/runtime/runtime-test.cc file should
be allowed to call such functions.
R=tmrts@chromium.orgCC=ahaas@chromium.org
Change-Id: Ib57bba36ba35f29c7673d4cef6d6b1e5ad9c7f65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339623
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69308}
The {name} parameter was unused, we always picked the exported "main"
function.
R=ahaas@chromium.org
Bug: chromium:1113681
Change-Id: Iee4b8f72e1137a7e366c3c31b4fa4e4ef81863b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345964
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69307}
* CopyElementsOnWrite
* CopyFixedArrayElements
* GrowElementsCapacity
There are two versions of CopyFixedArrayElements which still remain to
be TNodified and removed ParameterMode.
Bug: v8:9708, v8:6949
Change-Id: I0d63b51004aefbc55dfc57184ed9a0dda7c9b526
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339478
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69306}
A new field for signature type was added to WasmExportedFunctionData.
It is set to 0 or 1 depending on the parameter count.
(It's set and being used only in 0 and 1 parameter cases.)
Added new JS tests for 1 parameter wasm functions.
Bug: v8:10701
Change-Id: I349d881a2860f1a50b91e08d0126ca71c5f6483b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339622
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69302}
New space size needs to be adjusted during global safepoint.
Bug: v8:10315
Change-Id: I670024faa55ce68a4091af6f358f45d20c66fa0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2239573
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69301}
Previously, all ThisExpression's had kNoSourcePositions leading to
incorrect error messages like this:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: undefined is not a function
function t() { for (const x of this) {} } t();
^
TypeError: undefined is not a function
at t (unnamed:1:11)
at unnamed:1:43
This patch allows creation of a ThisExpression with a source position,
leading to a better error message:
➜ d8 -e "function t() { for (const x of this) {} } t();"
unnamed:1: TypeError: this is not iterable
function t() { for (const x of this) {} } t();
^
TypeError: this is not iterable
at t (unnamed:1:32)
at unnamed:1:43
This patch does not remove the existing cached version of
ThisExpression and instead creates a new one when required.
Bug: v8:6513
Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69300}
Rolling v8/build: 2943e82..a740400
Rolling v8/buildtools: 1ecfe3c..b00ad0a
Rolling v8/buildtools/linux64: git_revision:3028c6a426a4aaf6da91c4ebafe716ae370225fe..git_revision:e327ffdc503815916db2543ec000226a8df45163
Rolling v8/third_party/aemu-linux-x64: xa2xI0A-kKlMVwMtJRzexwWWPSwHynmUpB0Z6C9Y7wkC..OPyy2ts1trS4QpWQ4KGvoohvI1WfiBoTrjuFjdL-PcsC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/5cf00e2..c4d3ff4
Rolling v8/third_party/depot_tools: 24289f2..0fa91d0
Rolling v8/tools/clang: e6863f8..95f204aTBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I6b94a2aa7ecec9e2f3e158a54f21cd808720d6a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2341731
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#69296}
Up until now. we only checked the size of tables defined in a module
at instantiation time. For imported tables we only checked if the
imported table matched the declared import in size. This causes a
problem because we allocate function tables also for imported tabled
before we actually look at the imported table.
With this CL we first check the size of all tables, and only then start
to initialize and load them.
R=jkummerow@chromium.org
Bug: chromium:1114006
Change-Id: Iaf194ed21fb83304fe3a7f0f7ba7b282396e3954
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339473
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69291}
Forgetting to add a new bytecode into the lists in
serializer-in-background-compiler.cc results in a confusing CHECK
failure.
This moves the failure to a discoverable place.
Change-Id: I3e78b4702bfa724748ec8ed3f7f49e0eedc504fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2324246
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69290}
The cast from uint32_t to int caused an integer overflow that let a
bounds check succeed that should have failed.
R=jkummerow@chromium.org
Bug: chromium:1114005
Change-Id: Iea1af70af300be54c2a33d7dd10b3faa34d56eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339472
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69289}
The test have been rewritten to be more robust -> maybe they're
robust enough for the GC fuzzer (DelayedTasksPlatform)?
Bug: v8:10239
Change-Id: I743cc2f804357aaef888bff7985dfb68a7feec5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342848
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69287}
This CL unifies the custom events by creating
classes specialised based on the event type.
Multiple entry selection causes panels to
emit 'showentries' event. Single entry selection
causes panels to emit 'showentrydetail' event.
The events are received by the controller App class
and updates the view of the panels and state of the app.
Bug: v8:10644
Change-Id: Ibe26223459ba605c6d6d3f0025bf3a556dfb0578
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335188
Commit-Queue: Zeynep Cankara <zcankara@google.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69286}
They're not valid, since the embedder is allowed to process
tasks in several threads, if they do it in a thread safe manner.
Bug: v8:10239
Change-Id: I6c397a8bba75ab7aec3ee8ea8de416af817d9514
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342846
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69285}
This reverts commit 60ee70bb40.
Reason for revert: wasm-api-tests/WasmCapiTest.Serialize starts flaking: https://crbug.com/v8/10784
Original change's description:
> [wasm] Ensure that only TurboFan code is serialized
>
> We have the implicit assumption that Liftoff code will never be
> serialized, and we start relying on that when implementing new features
> (debugging, dynamic tiering).
>
> This CL makes the serializer fail if the module contains any Liftoff
> code. Existing tests are changed to ensure that we fully tiered up
> before serializing a module (similar to the logic in Chromium).
> The "wasm-clone-module" test needs to serialize the module before
> enabling the debugger.
>
> Note that chrome currently only serializes a module after it fully
> tiered up, so that should be fine. If other embedders need the ability
> to serialize a module in an arbitrary state, we will have to fix this
> later. With this CL we will be on the safe side though and (gracefully)
> fail serialization instead of accidentally serializing Liftoff code.
>
> R=ahaas@chromium.org
>
> Bug: v8:10777
> Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69276}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: Ic1349375bd562bb0a2724c39c27ef3247461c97b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342845
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69284}
Rolling v8/build: 2e78142..2943e82
Rolling v8/third_party/aemu-linux-x64: TfK3Whl6AfZifLOotcOS_jvckKztERlPvmVyZo16fN0C..xa2xI0A-kKlMVwMtJRzexwWWPSwHynmUpB0Z6C9Y7wkC
Rolling v8/third_party/android_platform: c1f84dc..5edcbfd
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ac60992..5cf00e2
Rolling v8/third_party/depot_tools: 486f181..24289f2
Rolling v8/tools/clang: 1078c41..e6863f8
Rolling v8/tools/luci-go: git_revision:56ae79476e3caf14da59d75118408aa778637936..git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f
Rolling v8/tools/luci-go: git_revision:56ae79476e3caf14da59d75118408aa778637936..git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f
Rolling v8/tools/luci-go: git_revision:56ae79476e3caf14da59d75118408aa778637936..git_revision:b022173f8069cf8001d4cf2a87ce7c5f0eae220f
TBR=machenbach@chromium.org,tmrts@chromium.org,v8-waterfall-sheriff@grotations.appspotmail.com
Change-Id: I783e91f9c10a8c295a9df81a16f85fdbecfcc13c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340190
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#69283}
The test relies on certain maps not dying but didn't ensure that.
Bug: v8:10783
Change-Id: I708f7fc027ee0bf5656be9bb4f29130f5b924597
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2340912
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69282}
This will ensure that the PersistentHandles are all created, and
in the OptimizedCompilationInfo before going into Exectute.
Bug: v8:7790
Change-Id: I1bc4f45153113c48422371498ff2cf79a1267737
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336803
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69280}
Now that we are using PersistentHandles, we don't need it anymore.
Bug: v8:7790
Change-Id: Id0b9d555191c00fb08dc2bb9099746076c5ad1b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332161
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69278}
