- 02 Mar, 2020 24 commits
-
-
Andreas Haas authored
Implements AtomicWait on 64-bit platforms. Note that this implementation does not use {PrepareCall}, as planned originally. This will be done in a separate CL, to prepare the implementation for 32-bit platforms. This CL for now unblocks the implementation on x64. R=clemensb@chromium.org Bug: v8:10108 Change-Id: I52eb752364b231043975f62913c2ef9579321038 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074400 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66537}
-
Toon Verwaest authored
This reverts commit 90b39673. Reason for revert: These functions are in use by d8-js.cc Original change's description: > [cleanup] Remove three unused proxy runtime functions > > R=jgruber@chromium.org > > Bug: v8:9183 > Change-Id: I789295e5bbea682b2e46ccf5a55c69dc74f0ed72 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617669 > Auto-Submit: Simon Zünd <szuend@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61632} TBR=jgruber@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9183, v8:10289 Change-Id: Ibd8566151f036efe73c869dcfd2cfee2a559489b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083299Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66536}
-
Seth Brenith authored
This is a reland of 25d16574 Changes from original: replaced slow test with fast test Original change's description: > [runtime] Improve handling of enumeration index on global dictionary > > Bug: chromium:1056054 > Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#66504} Bug: chromium:1056054 Change-Id: I45b9a096b1e37bf1dc5e792f106cdfadd47fabf9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080855Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66535}
-
Milad Farazmand authored
Port d303f4fb Original Commit Message: In the past we've used the isolate argument to signal whether we were in unicode mode (nullptr) or not (the real isolate). This is no longer needed, and in fact breaks no-i18n mode which always expects to have a real isolate. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2b8ede3c89738a6cec59f8e32657a3c8c815fe6a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081888Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66534}
-
Andreas Haas authored
Stack parameters in the StubCallDescriptor were set to the wrong type. I changed it now so that for stack parameters that are specified in the CallInterfaceDescriptor, type specified type is used. All other parameters are assumed to be tagged, as it has been until now. Original change's description: > [wasm] Refactor AtomicWait implementation > > The existing implementation included aspects that are not > straight-forward to implement in Liftoff and seemed inefficient: > * Convert the timeout in WebAssembly code from I64 to F64, just to > convert it back in the runtime. > * On 32-bit platforms this conversion needs an additional C-call. > * Split the I64 expected value from I64 into two I32 values in the > wasm-compiler. > * Ideally the int64-lowering takes care of 32-bit specific handling. > > With this CL the timeout and the expected value are passed as I64 to > the runtime (a builtin moves the I64 into a bigint for that). The > int64-lowering takes care of 32-bit platforms. There are special > builtins for 32-bit platforms, but they are written such that ideally > also the int64-lowering could create them. Bug: v8:10108 Change-Id: Ib87b543666708457c0d686208a86e46cdca3f9a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080362Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66533}
-
Georg Neis authored
Change-Id: Ibba52fe0c94dbb95ec66bc88d0a1e9a254094013 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080364 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Clemens Backes authored
The frame created by the WasmDebugBreak builtin now has a separate frame type, which will (later) allow to inspect the spilled registers. Once Liftoff supports reference types, this frame will also need special GC support for spilled heap references. R=jkummerow@chromium.org Bug: v8:10222 Change-Id: I110e51d1e6d09b0f44dcdd1cdcaafa2eaa64fddd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083013Reviewed-by:
-
Liviu Rau authored
Bug: chromium:1055078 Change-Id: Ifa421501cd19f445c2e0c0c87ab33563cef205cd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2077677 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66530}
-
Michael Achenbach authored
Bug: chromium:1055060 Change-Id: I9fd06642ba47d1452b33b0e97715dd2e64943c6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083027Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66529}
-
Leszek Swirski authored
Use macros to unify how HashTable (and subclasses) are marked as externally specialised, and how those specialisations are initialised. This cleanup will make it easier in the future to also add specialisations of HashTable methods for Isolate/OffThreadIsolate. Bug: chromium:1011762 Change-Id: Ibb62cf30d3ba40170e1d35ab72ada0f74963a5c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083023 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66528}
-
Igor Sheludko authored
This will help detecting TaggedIndex-related issues earlier. Bug: v8:10047 Change-Id: Ibd150e8ff77ec807977e0ee1b54c880620840bac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071261 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Georg Neis authored
Bug: chromium:1051017 Change-Id: I1729c059f4bc4fc75615fa0aa8dacf44dc56dad4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066968 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#66526}
-
Clemens Backes authored
This reverts commit c6c9d4bf. Reason for revert: Fails on noi18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/30737 Original change's description: > Update unicode-regexp-ignore-case-noi18n expectations > > There appear to be one or several bugs in noi18n mode such that > expectations in this test are no longer met. This CL updates > expectations to the current behavior and re-enables the test so we at > least preserve coverage in the other cases. > > The behavior in question should be investigated in the future > (low priority). > > Bug: v8:10120 > Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66524} TBR=jkummerow@chromium.org,jgruber@chromium.org Change-Id: I960b90fe3679ef4c04782ca9ac9b91454e636dbb No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10120 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083024Reviewed-by:
-
Jakob Gruber authored
There appear to be one or several bugs in noi18n mode such that expectations in this test are no longer met. This CL updates expectations to the current behavior and re-enables the test so we at least preserve coverage in the other cases. The behavior in question should be investigated in the future (low priority). Bug: v8:10120 Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I7c91e912feab227378810c91afe3de61e0e2fda8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081817 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
-
Georg Neis authored
Remove some duplication and make it easier to type a specific operation with given input types. Change-Id: I70d0424a1d1bd6330aa381568728d8313d5ad25d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078541 Auto-Submit: Georg Neis <neis@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Enable ArrayBufferExtensions by default. The last CL (https://crrev.com/c/2078585) that tried to enable this was reverted because of a TSAN failure. This was fixed in https://crrev.com/c/2078586. Bug: v8:10064 Change-Id: I2c3e0f2614323ea1521f2085b3c2bda5b69418ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083012Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#66521}
-
Jakob Gruber authored
In the past we've used the isolate argument to signal whether we were in unicode mode (nullptr) or not (the real isolate). This is no longer needed, and in fact breaks no-i18n mode which always expects to have a real isolate. Bug: v8:10120 Change-Id: I2f848c4ff8c2ff0e9b84278cbcdf3c3670e44e58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081816Reviewed-by:
-
Igor Sheludko authored
Bug: v8:10047, v8:10257 Change-Id: Idf7f5e0faf6b8d41795bb362b2473392cdb6e73d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2077682Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66519}
-
Victor Gomes authored
This add StackArgumentsAccessor class to ia32, which slighty increases abstraction when accessing arguments in the stack. Bug: v8:10201 Change-Id: I4ee0323022d9334cb0b2af63a9c1f437eed9a079 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2073762Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66518}
-
Seth Brenith authored
This fixes a build break in certain configurations. v8_debug_helper depends on generate_bytecode_builtins_list via the following headers: In file included from gen/v8/tools/debug_helper/heap-constants-gen.cc:5: In file included from ../../v8\src/common/ptr-compr-inl.h:10: In file included from ../../v8\src/execution/isolate.h:19: In file included from ../../v8\src/builtins/builtins.h:9: Change-Id: I38e5d851afc6ce52716d3e5e64ae9219df396bd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078768 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Leszek Swirski authored
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and make the OffThreadIsolate allocate "real" Handles. Rather than using the main-thread Isolate's handle scopes, these off-thread Handles are backed by a Zone, which is tied to the lifetime of the nearest OffThreadHandleScope. Eventually, we'll likely want to merge the implementation of OffThreadHandleScope and HandleScope, but currently the latter is too tightly coupled to the main thread to do so. Bug: chromium:1011762 Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Dominik Inführ authored
The JSArrayBuffer::extension-field might not be aligned with pointer compression enabled. However on AArch64 pointers need to be aligned if you perform atomic operations on them. Therefore split extension into two 32-bit words that each get updated atomically. There is no ABA problem here since the extension field only transitions from NULL --> value --> NULL. After Detach(), Attach() isn't invoked anymore. Bug: v8:10064 Change-Id: I20c1a37ac35d1749a94bfd277a4f91d531015bc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078586Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8c2d4f7..b03644a TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5f62d5448e47c9b05c9f6cb9e8dd8973d5ea77f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082005Reviewed-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@{#66514}
-
- 01 Mar, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/55ab41d..9ca9c52 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I133a199f46974bd3a283140d46b3475310eb17ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081992Reviewed-by:
-
- 29 Feb, 2020 4 commits
-
-
Mike Stanton authored
We can make better inlining decisions in TurboFan if the CallIC will provide the feedback that it's seen multiple closures that share the same SharedFunctionInfo. This is not difficult to do, and it fixes some frustrating performance cliffs. Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his project a year ago. Bug: v8:2206, v8:10100 Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/0a67df9..8c2d4f7 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/ef2f1b3..fa6ae42 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/21c99c4..03a5e99 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/780e6bf..55ab41d TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ida3c1cada6c21ef0cd0fb12d7018947de675fb29 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081454Reviewed-by:
-
Francis McCabe authored
This reverts commit 93253978. Reason for revert: Causing blink layout failures. See https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Future/2684 Original change's description: > Use context of then function for PromiseResolveThenableJob > > When a microtask is executed, we need to use an appropriate, > non-detached Context for its execution. Currently with > PromiseResolveThenableJobs [1], the Context used is always drawn from > the realm of the Promise constructor being used. This may cause > non-intuitive behavior, such as in the following case: > > const DeadPromise = iframe.contentWindow.Promise; > const p = DeadPromise.resolve({ > then() { > return { success: true }; > } > }); > p.then(result => { console.log(result); }); > > // Some time later, but synchronously... > iframe.src = "http://example.com"; // navigate away. > // DeadPromise's Context is detached state now. > // p never gets resolved, and its reaction handler never gets called. > > To fix this behavior, when PromiseResolveThenableJob is being queued up, > the `then` method of the thenable should be used to determine the > context of the resultant microtask. Doing so aligns with Firefox, and > also with the latest HTML spec [2][3]. > > This change is analogous to CL 1465902, which uses the realm of the > reaction handlers to determine the Context PromiseReactionJobs run in. > > [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob > [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments) > [3]: https://github.com/whatwg/html/pull/5212 > > Bug: v8:10200 > Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66507} TBR=verwaest@chromium.org,timothygu@chromium.org,syg@chromium.org Change-Id: I81737750f8b369567ba586c5a2cfb489836b7e74 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10200 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081091Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#66510}
-
Johannes Henkel authored
"Tweaks for emitting JSON" https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2071518 Change-Id: Ie05ff1390a5340e15c21788c58e8171cb442da10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2073205Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66509}
-
- 28 Feb, 2020 11 commits
-
-
Deepti Gandluri authored
Change-Id: Iaf8e02b201c547fb8b74a7e7f2defd4bfbc098d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079049Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#66508}
-
Timothy Gu authored
When a microtask is executed, we need to use an appropriate, non-detached Context for its execution. Currently with PromiseResolveThenableJobs [1], the Context used is always drawn from the realm of the Promise constructor being used. This may cause non-intuitive behavior, such as in the following case: const DeadPromise = iframe.contentWindow.Promise; const p = DeadPromise.resolve({ then() { return { success: true }; } }); p.then(result => { console.log(result); }); // Some time later, but synchronously... iframe.src = "http://example.com"; // navigate away. // DeadPromise's Context is detached state now. // p never gets resolved, and its reaction handler never gets called. To fix this behavior, when PromiseResolveThenableJob is being queued up, the `then` method of the thenable should be used to determine the context of the resultant microtask. Doing so aligns with Firefox, and also with the latest HTML spec [2][3]. This change is analogous to CL 1465902, which uses the realm of the reaction handlers to determine the Context PromiseReactionJobs run in. [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments) [3]: https://github.com/whatwg/html/pull/5212 Bug: v8:10200 Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by:Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66507}
-
Frank Tang authored
We need to track misc features launched in 2019 to understand the impact. Also we need to measure the v8BreakIterator usage of 'word' and 'line' to lobby the need for 'line' in the replacement standard Intl.Segmenter which an Apple engineer opposed to include. Bug: v8:10251 Change-Id: I5d4cbe6ccf458c9ec4adfebad235f9c6dcd2ac37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067512Reviewed-by:
-
Francis McCabe authored
This reverts commit 25d16574. Reason for revert: breaks tree with new flakes. See, for example: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/31169 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/21895 https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/8490 Original change's description: > [runtime] Improve handling of enumeration index on global dictionary > > Bug: chromium:1056054 > Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#66504} TBR=jkummerow@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com,victorgomes@chromium.org Change-Id: I2baa48f6ed2b0b3e23b0d705b6a805d76ee4bb8f No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1056054 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080653Reviewed-by:
-
Seth Brenith authored
Bug: chromium:1056054 Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035Reviewed-by:
-
Seth Brenith authored
Previously, our Torque definition of JSArrayBuffer included only the first two fields. This allowed access to those two fields, but was somewhat confusing and obviously didn't let Torque code access the other fields. This change: - Completes the JSArrayBuffer layout definition; - Moves the associated bitfield struct definition to Torque; - Moves a couple of JSArrayBuffer macros to Torque; - Adds a reducer case so that the code generated using these new macros is not worse than what was generated previously. Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
-
Milad Farazmand authored
More instructions are being emitted with 242d58e3 hence the offset needs to be updated. Change-Id: I892920837ca7d785eb423503921ee39134be1c0d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079156Reviewed-by:
-
Ambroise Vincent authored
The ArchLookupSwitch implementation has been completely replaced by ArchBinarySearchSwitch, leaving dead code behind. Change-Id: I7fd6306cb0f5562c10e32293f5ea13bbd3bf7067 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2077684 Commit-Queue: Rodolph Perfetta <rodolph.perfetta@arm.com> Reviewed-by:
-
Emanuel Ziegler authored
This fixes a crash related to access after free on platforms that store the MacroAssembler as a pointer. The intended behavior is restored by explicitly setting the flag in the macro assembler instead of using NoRootArrayScope. Landing as TBR as it's blocking fuzzers and fix seems simple enough. TBR=jgruber@chromium.org R=jyan@ca.ibm.com R=miladfar@ca.ibm.com Bug: chromium:1057018 Change-Id: Ib6de82b47bb1abb74da58b3d476b359669372bb5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080242 Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org> Reviewed-by:
-
Maya Lekova authored
The interface for ArgumentInfo was allowing out-of-bounds read from the returned array. Improved that by passing the index explicitly as a parameter and checking against the expected bounds. Bug: v8:10267 Change-Id: Ic1022def3e338598cd9bd9e6582d67a62836d0db Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078578Reviewed-by:
-
Sathya Gunasekaran authored
This reverts commit 77d4e230. Reason for revert: verify csa build bot broken https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/16218? Original change's description: > [wasm] Refactor AtomicWait implementation > > The existing implementation included aspects that are not > straight-forward to implement in Liftoff and seemed inefficient: > * Convert the timeout in WebAssembly code from I64 to F64, just to > convert it back in the runtime. > * On 32-bit platforms this conversion needs an additional C-call. > * Split the I64 expected value from I64 into two I32 values in the > wasm-compiler. > * Ideally the int64-lowering takes care of 32-bit specific handling. > > With this CL the timeout and the expected value are passed as I64 to > the runtime (a builtin moves the I64 into a bigint for that). The > int64-lowering takes care of 32-bit platforms. There are special > builtins for 32-bit platforms, but they are written such that ideally > also the int64-lowering could create them. > > R=jkummerow@chromium.org, binji@chromium.org > > Bug: v8:10108 > Change-Id: I2dbba5839779961b1c5bde4c23fc3f38f1895a52 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071867 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ben Smith <binji@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66497} TBR=binji@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org Change-Id: If284aa07eedddd2fbea4df8c53c7d371cac1d42e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10108 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080250Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#66498}
-
