- 07 Jun, 2021 37 commits
-
-
Igor Sheludko authored
Bug: chromium:1216437 Change-Id: Ib8439aefc778beefed4dc40290473311cc23d5f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944937Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#74994}
-
Chong Gu authored
This will allow Fuchsia tests to be run on v8 CI Bug: v8:11843, chromium:934932 Change-Id: I516329d8f29d9c94d46aa010fa729fa3ca0993ee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2935024 Commit-Queue: Chong Gu <chonggu@google.com> Auto-Submit: Chong Gu <chonggu@google.com> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74993}
-
Seth Brenith authored
The flag --trace-ignition-dispatches has been broken for a long time, since it was not designed to work with bytecode handlers that are generated ahead of time by mksnapshot. This splits the existing --trace-ignition-dispatches logic into two separate parts: 1. A gn argument which instructs mksnapshot to include dispatch counting in the bytecode handlers, and ensures that the Interpreter allocates the array of counters, and 2. A runtime flag which enables the ignition-statistics extension which implements the JS-accessible function getIgnitionDispatchCounters(). Change-Id: I89323425697f5641451f67b9ddcc0303b8ca209f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2937564Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74992}
-
Patrick Thier authored
xmm0 and xmm1 are used to save/restore values in asm builtins, but they were not saved before calling RecordWrite, which calls C++ code. Instead of passing SaveFPRegsMode::kSave to RecordWriteField, which would save/restore all FP-regs, this CL explicitly saves/restores the FP-regs we rely on beyond the C-Call. Bug: chromium:1216295 Change-Id: Ifcc7ce4e8819303ffb79576a88304df2e3a6cc4c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944427Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74991}
-
Patrick Thier authored
Add flag --lazy-feedback-allocation to prevent NumFuzz errors. Bug: v8:11853 Change-Id: I5170ef9db374e168cf248b86dbed3c3e7c87f826 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944428Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74990}
-
Dominik Inführ authored
Left-trimming only works when there is a single reference to the backing store from the JS object. Main thread handles are an exception to this rule because it is not feasible to ensure that no such leftover handles may store such stale pointers. FixStaleLeftTrimmedHandlesVisitor clears such references in main thread handles, such that the GC never tries to visit them. This CL renames this class to ClearStaleLeftTrimmedHandlesVisitor to emphasize that such slots are cleared rather than "fixed up" to point to the new object start. Previously ClearStaleLeftTrimmedHandlesVisitor was used for local and persistent handles as well. Starting with this CL, stale references to left-trimmed objects are only allowed in main thread handles. https://crrev.com/c/2928502 enabled us to be more restrictive here. Change-Id: If4db0630f1df2d6c3fe5f242bf866c57a8ae2969 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944807Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74989}
-
Igor Sheludko authored
Bug: chromium:1216437 Change-Id: Ic417583813ccef4d93b46d5b53af6dd0e6ba9840 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940889 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#74988}
-
Camillo Bruni authored
- Introduce proper TickLogEntry and use a separate Timeline object - Update the main rendering to use SVG for speed - Separate custom-elements: timeline-track-map and timeline-track-tick - Revamp flame-chart drawing - Enable map-transitions overlay - Use mouse position to infer current log-entry instead of individual event handlers - Fix first timelineLegend column header - Fixing scrollbar-color for FireFox Change-Id: I7c53c13366b3e4614b1c5592dfaa69d0654a3b5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944430 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#74987}
-
Marja Hölttä authored
This fix makes ObjectLiteral::CalculateEmitStore work correctly. Bug: v8:11810 Change-Id: I60f3d5cb657f4b2ca574d5224c8f1cb7a8216354 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917040Reviewed-by:
-
Camillo Bruni authored
Use new Script.prototype.update method to set the url and the script source. Bug: v8:11850 Change-Id: I555d4d0158cdacb7cb42efa385371454542fc2f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944438Reviewed-by:
-
Santiago Aboy Solanes authored
We have recursive calls such ThinStrings where we go String::Get into ThinString::Get into String::Get again for the internalized string. If we need to, we would acquire the StringAccessGuard in the first String::Get and it wouldn't be needed to be re-acquired for the second String::Get. Trying to re-acquire it would in fact be an error since we are already holding the lock. The code, however, didn't know if we acquired it or not. It was working correctly due to the way the methods were defined and called. By passing down the access guard through the Get() calls we make this interaction explicit. Also add some thin string tests to test the interaction. Bug: v8:7790 Change-Id: I1181edec1e802cb754c4d1d1ac268577257b92f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936598 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74984}
-
Lu Yahan authored
Change-Id: Ia1dfb428e5518343252300bf4323f24a20bb7f2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939539 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Reviewed-by:
Brice Dobry <brice.dobry@futurewei.com> Cr-Commit-Position: refs/heads/master@{#74983}
-
Andreas Haas authored
A spec test (wasm-js/global/value-get-set) requires WebAssembly.Global.value.set to throw an exception if it is called with 0 arguments. The implementation in V8, however, just checked if the first parameter is `undefined`. This implementation indeed threw an exception if 0 arguments were provided, but it also threw an exception when `undefined` is provided as a parameter. This, however, violates the spec, because globals can be reset to `undefined`. With this CL we replace the checking for `undefined` by checking the length of the arguments that get provided. R=ecmziegler@chromium.org Bug: chromium:1211342 Change-Id: Ic87a0b369dea3e49eddb8f71f2c29dc6a8f5f558 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940901Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#74982}
-
Jakob Kummerow authored
instead of recursive. JS code can construct very long chains of nested bound functions or proxies, where the previous recursive implementation could run out of stack space. Fixed: chromium:1214616 Change-Id: I764718f03030d22c0873b3ed05277d4317789093 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933668 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Clemens Backes authored
When growing a memory without a maximum, we should still check against the spec'ed limit, to avoid an overflow when computing the new number of pages. R=ahaas@chromium.org Bug: chromium:1215808 Change-Id: I476b954268277e7dce1106a9b8c3c713b0d1a560 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944433Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74980}
-
Dominik Inführ authored
While no scavenger thread reads the content of an object copied by another thread, we still need memory ordering in order to read the page flags for a forwarded object. Change-Id: I831e9dccb03d32daf3c4847613614d26533ba825 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944436Reviewed-by:
-
Michael Achenbach authored
This reverts commit 6596e8c6. Reason for revert: Main bug was fixed. Original change's description: > [infra] Switch back to Xenial on some bots > > This tests the hypothesis that the current timeout problems are on > Bionic bots only. > > Bug: v8:11818 > Change-Id: I68f84cda52ca392fbda5a400eb2bf136b7ee85a3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2916816 > Auto-Submit: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74747} Bug: v8:11818 Change-Id: Ib5f952dc6f23f3a98bb1d79ae5ce689e288d6727 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940897 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74978}
-
Jakob Gruber authored
.. and replace them by elements read directly from the heap object. With this change, consistency between `map` and `elements` is no longer guaranteed. Users were updated, when necessary, to deal with this, e.g. by being more careful not to read out of bounds, by inserting new `actual_elements == elements_constant` runtime checks, or through a new compilation dependency that verifies unchanged elements at finalization time. Drive-by: inline GetElementsKind into callsites. Bug: v8:7790 Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655Reviewed-by:
-
Jakob Kummerow authored
Change-Id: I244a28e29f14b05a50c8bb10db429b16b2052aca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944432Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74976}
-
Clemens Backes authored
We currently take the sample at the moment the isolate is created. At that point, the embedder callback for taking samples is not installed yet. Hence delay taking the sample until the first module is created. This will only take samples for isolates that actually use wasm, which will reduce the overall number of samples, but will give a better picture of PKU support for Wasm. R=jkummerow@chromium.org CC=dlehmann@google.com Bug: v8:11714 Change-Id: I8a4163961c06076efd6c5dde5751682b53863c2c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944429Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74975}
-
Clemens Backes authored
This reverts commit 79d63a5e. Reason for revert: Breaks predictable: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20predictable/36887/overview Original change's description: > [wasm] Remove all implications from --predictable > > In predictable mode, we want to execute the same code as otherwise, > modulo timing. Hence remove any implications which change behaviour > (like tier-up or asynchronous compilation). > Note that --predictable is a debugging flag, so the configurations does > not need to "make sense" in production. > > R=ahaas@chromium.org > > Bug: v8:11848 > Change-Id: If74fbacadeb087d977922c41f33fd18738b50ded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940898 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74973} Bug: v8:11848 Change-Id: I20eaf665e8ce63af8aeffe3bac7a45372ad6ab7b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2944434 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#74974}
-
Clemens Backes authored
In predictable mode, we want to execute the same code as otherwise, modulo timing. Hence remove any implications which change behaviour (like tier-up or asynchronous compilation). Note that --predictable is a debugging flag, so the configurations does not need to "make sense" in production. R=ahaas@chromium.org Bug: v8:11848 Change-Id: If74fbacadeb087d977922c41f33fd18738b50ded Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940898 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Manos Koukoutos authored
Change-Id: Id502aa02a778d17c32996b0438ac3a7c85166430 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940892Reviewed-by:
-
Santiago Aboy Solanes authored
Introduce EmitTSANStoreOOLIfNeeded methods which make it easier on the eyes in code-generator.cc. Also pass along the size, which lays the groundwork for the other instructions e.g. kX64Movq since we don't require the store to be a Tagged one. This creates new builtins (since we now have a version with 32 bits and another one for 64 bits stores). We can extract the common code in builtins-internal-gen.cc to de-duplicate the common code. Bug: v8:7790, v8:11600 Change-Id: I81d80b852ec96b94d170a20f6d61621743b74b32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933664Reviewed-by:
-
Clemens Backes authored
This is a reland of 5fd38582. It adds back all recursive implications (via --single-threaded), such that we can remove them individually in follow-up CLs and watch the state of the predictable bot. Original change's description: > [flags] Predictable should not imply single-threaded > > The --predictable flag is often used to reproduce issues, and having it > imply --single-threaded can change decisions like which compiler(s) to > use. This is because --single-threaded is meant to be set by embedders > (hence we do our best to support single-threaded execution), whereas > --predictable is a testing-only flag which should not change semantics > too much. The fact that --predictable executes everything in a single > thread is already implied by the PredictablePlatform. > > R=ahaas@chromium.org, machenbach@chromium.org > CC=jkummerow@chromium.org > > Change-Id: Ic174dd59dfdbd6aa1a410f983db05db26c944cd5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2919828 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74822} Change-Id: I7a060826761781727870dd96fffc42ced4675e76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933143 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
This is a reland of 81dd3f42, which was a reland of 59eff3bf Original change's description: > [bigint] Karatsuba multiplication > > The Karatsuba algorithm is used for BigInts with 34 or more internal > digits, and thanks to better asymptotic complexity provides greater > speedups the bigger the inputs. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2782283 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74916} Bug: v8:11515 Change-Id: I08f7d59dfa39fb3b532684685afd9fa750e0e84e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933666Reviewed-by:
-
Marja Hölttä authored
Bug: v8:11525 Change-Id: I0ac9f252e0de16480036e3630edf7efefe8d8571 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928501Reviewed-by:
-
Mathias Bynens authored
Bug: chromium:1213927 Change-Id: I85f5559863524717355ec61694ce007a2be7c8a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2931799Reviewed-by:
-
Clemens Backes authored
Since there is only a single thread in predictable mode, we should never wait for more work. That would be an immediate deadlock. This CL adds code to never wait, and instead checks after processing all messages that we would not need to wait (i.e. that all work was completed). This turns deadlocks into FATAL errors. R=ahaas@chromium.org Bug: v8:11848 Change-Id: If61305d634803fc43678238dc6e9d3a2f35793c8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940886Reviewed-by:
-
Jakob Kummerow authored
Strict equality checking of ValueTypes only made sense before reference types came along. Change-Id: I632f541328cb27ae87a5e3daccd4ffb9cfc8a502 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928513 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#74965}
-
Andreas Haas authored
Bug: chromium:1213097 Change-Id: If768725a5645b7d21f59845692ca5491e8674bfa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940896Reviewed-by:
-
Dominik Inführ authored
Prepare method by taking an object as argument. In the future we can optimize this method by only sweeping the object's page. Bug: v8:11837 Change-Id: Ife1ee7949bfaf590dcc305cc4d03aa1813c07b76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940888Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74963}
-
Clemens Backes authored
This fixes a little mistake from https://crrev.com/c/2182453. In predictable mode (where we do not have any threads for executing background work) we are executing everything on the main thread, but we should never wait for background work to be spawned. Otherwise we can deadlock if the last background task spawned new foreground work, but we keep waiting for more background work to arrive. Generally, any blocking in predictable mode will block forever, because there is no one to spawn any work concurrently (foreground or background). But the blocking for foreground work has to be there for non-predictable mode, thus keep it for now, and only remove waiting for background work. R=ahaas@chromium.org Bug: v8:11848 Change-Id: I51c976f6858db8120baa4c47d28840a1041d7fea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940885Reviewed-by:
-
Michael Achenbach authored
This reverts commit d1e1f1be. Reason for revert: Main bug was fixed. Original change's description: > [infra] Switch back to Xenial on a slow variant > > This is to mitigate flaky timeouts due to memory problems on some > Bionic bots. > > Bug: v8:11818 > Change-Id: I4758f0f167b94d81f43e183a5599a39d8545b4e1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2922245 > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Auto-Submit: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74824} Bug: v8:11818 Change-Id: I9719cbcd074de44cd5fb981c40f46bf4e10adee0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2940895 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#74961}
-
Michael Lippautz authored
This aids debugging as it gives the root set a name. Bug: chromium:1164553, chromium:1186901 Change-Id: I2c2aed369823b059629b35bb170b4966b47156d0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933661 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#74960}
-
Paolo Severini authored
The tests are not compatible with the --stress-background-compile flag. Bug: v8:11821 Change-Id: Iecef6a2838109fddc9f0ecc145a9f8971bc9bc3c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2918214Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/092e09c..8bf7a0b TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: Ib98bf84acfa7c1c13305dcf2dfcb9a32bf1a66a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2942625Reviewed-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@{#74958}
-
- 06 Jun, 2021 2 commits
-
-
Dominik Inführ authored
This is a reland of b0c70710 The first CL got reverted because of build errors. This CL replaces the remaining usage of is_local_space() with is_compaction_space(). Supposedly this was a leftover because https://crrev.com/c/2928189 landed at roughly the same time. Original change's description: > [heap] Remove unused LocalSpace class > > LocalSpace was introduced for off-heap spaces with concurrent bytecode > compilation finalization. However, finalization ended up using > LocalHeap for concurrent allocations. LocalSpace is therefore unused > and can be removed. > > This CL removes LocalSpace and renames all mentions of local space to > compaction space. Compaction space was the only local space left. > > Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74914} Change-Id: I993c47fe85f4140f5d6137afde2653a48047cafb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939983Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/74cfeda..e353b02 TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: I2488e4e16cf75067122d61652303d6fad2b5cd25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2942922Reviewed-by:
-
- 05 Jun, 2021 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1da98aa..74cfeda Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/712eb08..092e09c Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/9705687..a5b6b2f Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/af7a363..30cbc5c Rolling v8/tools/luci-go: git_revision:c9957ed0ce0fd363aac127056344eba1b873bad0..git_revision:2cc9805d5ad186367461ef1c4f0c59098b450418 Rolling v8/tools/luci-go: git_revision:c9957ed0ce0fd363aac127056344eba1b873bad0..git_revision:2cc9805d5ad186367461ef1c4f0c59098b450418 Rolling v8/tools/luci-go: git_revision:c9957ed0ce0fd363aac127056344eba1b873bad0..git_revision:2cc9805d5ad186367461ef1c4f0c59098b450418 TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: I202053812c034c82bfd70aa9821685eb981d6335 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939053Reviewed-by:
-
