- 11 Mar, 2020 16 commits
-
-
Santiago Aboy Solanes authored
This CL is a step towards making StackChecks implicit. In a follow-up CL said StackChecks will become implicit within JumpLoops. Cq-Include-Trybots: luci.chromium.try:linux-rel Bug: v8:10149, v8:9960 Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66668}
-
Z Nguyen-Huu authored
We want to be consistent with wasdk/wasmparser. Unnamed function's name would be func# Doc: https://docs.google.com/document/d/1XoXWONLBgZWQ9dhtoMpQPvD0fnnWA50OorsuSXfME3g Bug: v8:10242 Change-Id: I12222eef38a57242e9f606007d0ffa76b8e2a4af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084052 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#66667}
-
Andreas Haas authored
The return value of {memory_copy_wrapper} was defined as {bool} in the original CL. When compiled with clang, the full return register is written when {true} or {false} is returned. With msvc, however, the return value is written as a single byte, without zero-extension. In generated code, the full return register is used and therefore stale bytes in the return register caused problems. With this CL the return value is changed to {uint32_t}. This enforces zero-extension of the return value and thereby fixes the issue. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I628d01cfd7193fa960a7ccdf0d9fd896f510cd3e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096626 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: -
Milad Farazmand authored
Change-Id: I88c43793b82256e9f37ffd54468fd0374fedd164 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097025Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66665}
-
Jakob Kummerow authored
Because run-tests.py still requires it. No-try: true Change-Id: Ief1f3d7a93ba4c36232420ee9ab0a4ff3ea6739b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096628 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#66664}
-
Dominik Inführ authored
Instead of directly using the Heap class concurrent threads will use the LocalHeap class for all heap operations. Bug: v8:10315 Change-Id: Ie007abb5b914af7f2507c9e790f34baacbcdf588 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096620 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66663}
-
Milad Farazmand authored
Port 485e66ba R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2e1b79a995661243ff05b3d13e310f6315de0c97 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097450Reviewed-by:
-
Matheus Marchini authored
Node.js build fails on VS2017 without these headers, see the downstream issue (https://github.com/nodejs/node-v8/issues/128). Co-authored-by:
Ben Noordhuis <info@bnoordhuis.nl> Co-authored-by:
gengjiawen <technicalcute@gmail.com> Change-Id: I771eab435dce5cf548581f3acd78681180c77692 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093951Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66661}
-
Milad Farazmand authored
Some wasm interpreter tests are failing since instructions generated by gcc such as *multiply and and* create intermediate results bigger than 8 bytes which doesn't match other architectures, hence the resulting output differs. Change-Id: I68cc58d01699bfe93051da693c4b7e819ffcc6eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095613 Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Reviewed-by:
-
Georg Neis authored
Generalize the HeapConstant case to a Singleton case. Change-Id: Ief8c325a4326e02c8c361f3b41fc40ca398167ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096619 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit c475e704. Reason for revert: Fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805 Original change's description: > [wasm] Do memory.copy bounds check in C++ code > > In the existing implementation we first did a bounds check in generated > code, and then called a simple C++ function to do the actual copying. > With this CL now we pass the WasmInstanceObject to the C++ function in > addition to the memory.copy parameters. Thereby we can do the bounds > check in C++, which is much easier, less error prone, and which also > speeds up code generation and reduces code size. Performance should not > be worse, because we were already doing the call to C++ anyways. > > R=clemensb@chromium.org > > Bug: v8:10281 > Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66655} TBR=ahaas@chromium.org,clemensb@chromium.org Change-Id: Ic2491f635a292e004f6c95498a045ba102138dc5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096623 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit c7a26b13. Reason for revert: Need to revert previous CL because it fails on MSVC: https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/12805 Original change's description: > [wasm] Do memory.init bounds check in C++ code > > In the existing implementation we first did a bounds check in generated > code, and then called a simple C++ function to do the actual copying. > With this CL now we pass the WasmInstanceObject to the C++ function in > addition to the memory.init parameters. Thereby we can do the bounds > check in C++, which is much easier, less error prone, and which also > speeds up code generation and reduces code size. Performance should not > be worse, because we were already doing the call to C++ anyways. > > R=clemensb@chromium.org > > Bug: v8:10281 > Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66656} TBR=ahaas@chromium.org,clemensb@chromium.org Change-Id: I1064113e7f1c445d04652a973c994317fd3e739a No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10281 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096624Reviewed-by:
-
Andreas Haas authored
In the existing implementation we first did a bounds check in generated code, and then called a simple C++ function to do the actual copying. With this CL now we pass the WasmInstanceObject to the C++ function in addition to the memory.init parameters. Thereby we can do the bounds check in C++, which is much easier, less error prone, and which also speeds up code generation and reduces code size. Performance should not be worse, because we were already doing the call to C++ anyways. R=clemensb@chromium.org Bug: v8:10281 Change-Id: Ia86e1d08001a8bc7556277abeaa9208ec1128f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096621 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Andreas Haas authored
In the existing implementation we first did a bounds check in generated code, and then called a simple C++ function to do the actual copying. With this CL now we pass the WasmInstanceObject to the C++ function in addition to the memory.copy parameters. Thereby we can do the bounds check in C++, which is much easier, less error prone, and which also speeds up code generation and reduces code size. Performance should not be worse, because we were already doing the call to C++ anyways. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I24488d92056f0b5df27a61783a274895bd37cc24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093434 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9b4e026..3e21004 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/abdb603..a8e510a Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a12175c..552ddbf Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/luci-go: git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6..git_revision:de73cf6c4bde86f0a9c8d54151b69b0154a398f1 Rolling v8/tools/swarming_client: https://chromium.googlesource.com/infra/luci/client-py/+log/0ac2847..cc95827 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I59b2eb12c51114c798fbbc9008952952736ebe7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2097639Reviewed-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@{#66654}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I6766c1d0f347f8e0c8dea588e5984eb48ad18d5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094198Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
-
- 10 Mar, 2020 14 commits
-
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ic309d394620ec17791bac2902116e15058b28a68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091634Reviewed-by:
-
Dominik Inführ authored
Report the allocated size of global handles in GetHeapStatistics as well, not including free handles. Bug: chromium:1060192 Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Richard Townsend authored
Suffered from a confusion of masm/marmasm syntax for the x64 host and arm64 target (could only generate one syntax or ther other). Fixed by moving the compile-time flag to a runtime one. Bug: v8:10012 Change-Id: I34746a495b1881c1d0465995930979bb768b07e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962854Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Richard Townsend <richard.townsend@arm.com> Cr-Commit-Position: refs/heads/master@{#66650}
-
Leszek Swirski authored
Rather than having an optional script id during ParseInfo creation (which is either selected lazily on script creation, or eagerly if based on an existing Script), always eagerly get either the desired script id (either from the Script or Isolate::GetNextScriptId()). This has the side-effect that we will currently no longer need to get the script id on background threads, but I'm not reverting the thread-safety of Isolate::GetNextScriptId in case it's needed again in the future. Bug: v8:10314 Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Previously, ParseInfo would create a script (with CreateScript) based on its flags, and then set its own flags based on that created script. This created a weird circular dependency for some of those flags, and sometimes we would have valid flags before script creation (main thread compile), while other times not (streaming compile). Now we set the ParseInfo flags manually and uniformly before script creation, and check that they match the created script after it has been created. Bug: v8:10314 Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Victor Gomes authored
The arguments order in a JS stack is now controlled by V8_REVERSE_JSARGS macro. This CL creates two stubs that allow the order of the arguments to be reversed without changing CallStub. Bug: v8:10201 Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66647}
-
Dan Elphick authored
Useful for profiling why mksnapshot is so slow in conjunction with --runtime-call-stats. Change-Id: Ib193d292352e0019b93c8edccb38a904aadbf553 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089932Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#66646}
-
Janusz Majnert authored
Torque compiler emits a C++ class definition header class-definitions-tq.h. Unfortunately it does so in a manner that introduces randomness into the ordering of some structs. This means that every full build of V8 may yield a different header. Since this header is included in a lot of files in V8, it causes a lot of ccache misses (over a 1000). This commit makes sure that the structs are emitted in lexical order. Bug: v8:10310 Change-Id: Ie39066d36e41583ff990bc639f7f241462351585 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093500 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Milad Farazmand authored
Port b766299d Port 9592b043 Port d915b8d6 Original Commit Message: Code object iteration was missing logic for RELATIVE_CODE_TARGET reloc entries. Garbage collection could thus miss objects that were referenced only as targets of pc-relative calls or jumps. RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only at mksnapshot-time. This exposed another issue in that the interpreter entry trampoline copy we generate for profiling *did* contain relative calls in runtime-accessible code. This is a problem, since code space on arm is, by default, too large to be fully addressable through pc-relative calls. This CL thus also disables the related FLAG_interpreted_frames_native_stack feature on arm. objects. R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693Reviewed-by:
-
Leszek Swirski authored
Change wrapped argument set-up to be closer to where it's needed: setting up a top-level SFI, or initializing a ParseInfo from a top-level SFI. This is a generally cleaner use of the interface, avoids splitting the setting of the funciton syntax kind and wrapped arguments (including checking script.is_wrapped() in two places for the same behaviour), plus it avoids unnecessarily creating wrapped_argument handles for functions inside a wrapped script. As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags from a script for top-level vs. non-top-level. Bug: v8:10314 Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Jakob Kummerow authored
The code was almost compatible, only one small issue had snuck in. No-try: true Change-Id: I52225fb2092bf16a5fffbde957cd1dfe4f2c4fd6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093492Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66642}
-
Iain Ireland authored
Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a case-folding algorithm that doesn't quite match the Unicode definition. There are two places in irregexp that need to do case-folding. Prior to this patch, neither of them quite matched the spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch). This patch implements the "Canonicalize" algorithm in src/regexp/special-case.h, and uses it in the relevant places. It replaces special-case logic around upper-casing / ASCII characters with the following approach: 1. For most characters, calling UnicodeSet::closeOver on a set containing that character will produce the correct set of case-insensitive matches. 2. For a small handful of characters (like the sharp S that prompted this change), UnicodeSet::closeOver will include some characters that should be omitted. For example, although closeOver('ß') = "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß' canonicalizes to itself, and should not match 'ẞ'. In these cases, we can skip the closeOver entirely, because it will never add an equivalent character. These characters are in the IgnoreSet. 3. For an even smaller handful of characters, UnicodeSet::closeOver will produce some characters that should be omitted, but also some characters that should be included. For example, closeOver('k') = "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN SIGN should not match either of the other two (step 3.g). To handle this, we put such characters in the SpecialAddSet. In these cases, we closeOver the original character, but filter out the results that do not have the same canonical value. The computation of IgnoreSet and SpecialAddSet happens at build time, using the pre-existing gen-regexp-special-case.cc step. R=jgruber@chromium.org Bug: v8:10248 Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858Reviewed-by:
Frank Tang <ftang@chromium.org> Reviewed-by:
-
Daniel Bevenius authored
Change-Id: If9ef15e1ecbb75b7542b8033f68e63ba1a08cae1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091470Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1739acf..9b4e026 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/fa6ae42..1a8a3a7 Rolling v8/buildtools/linux64: git_revision:4166e9fbc1fa5ceab69b69710a0f8b430c50127b..git_revision:fd3d768bcfd44a8d9639fe278581bd9851d0ce3a Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c5f5b9e..abdb603 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ffd0295..a12175c Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0f734f7..0a95832 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib266db1413cabf622559762833896b304d6deeb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095247Reviewed-by:
-
- 09 Mar, 2020 10 commits
-
-
Ng Zhi An authored
In https://crrev.com/c/2084321 I added s128 load store to the fuzzer, and updated the memop generator to use IsPrefixOpcode check. But it was used wrongly. IsPrefixOpcode checks a 1 byte opcode and see if it is a prefix opcode, but if memory_op is already a 2 byte opcode, it will fail the IsPrefixOpcode check. Bug: chromium:1059899 Change-Id: I4caadfb2feaf42ebb9f5578cb790ef8a1d08d173 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095681Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66638}
-
Shu-yu Guo authored
Previous commit incorrectly inlined ToIntegerImpl into ToInteger_Inline, causing code bloat. Bug: chromium:1059364 Change-Id: I7bc369255a29a7ea567fafc775835c37584905b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2092843 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Joyee Cheung authored
When looking for private members in an object for the inspector, we check if that object is a class constructor with the a bit has_static_private_methods set on its SFI. If it is, we look for any variables in the context locals with a VariableMode associated with private methods or accessors and a IsStaticFlag being kStatic. This patch also filters out static private methods when inspecting instances. Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit Bug: v8:9839, v8:8330 Change-Id: Idad15349c983898de2ce632c38b0174da10e639d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#66636}
-
Frank Tang authored
These two tests was fixed by ICU rolling to 0b6134378 See https://chromium-review.googlesource.com/c/chromium/src/+/2090002 File new bug 10313 to track the unrelated issue in built-ins/Date/parse/without-utc-offset Bug: v8:9612, v8:9474, v8:10313 Change-Id: I26f5857f3c4b6000b3585600bc3ed2f2ed29a043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095394Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66635}
-
Z Nguyen-Huu authored
Bug: v8:10290 Change-Id: I35670fef49a89cd075fb654daec4b55440266673 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2088231 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Seth Brenith authored
Bill kindly pointed out to me that v8windbg was not handling bit_field2 correctly. The issue was that the constexpr type for ElementsKind was, somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully- qualified type name like "v8::internal::ElementsKind". This change addresses the problem in two ways: 1. Update v8windbg's type resolution logic to resolve type names as if they were used in the v8::internal namespace. This makes it more consistent with how those type names are used in other generated Torque code, reducing surprises and the number of times we have to write `v8::internal::` in .tq files. 2. Add compile-time verification that any constexpr type name used as a string in class-debug-readers-tq.cc can also resolve as a type name. Bug: v8:9376 Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769Reviewed-by:
-
Ng Zhi An authored
When dst is a fp pair, we set both low and high fp regs. Later when we look at set regs to determine which registers to load into, we examine both low and high fp. This is wrong - we only need to look at the low fp, since Fill will load into the correct fp pairs. The bug was triggered because we were examining into junk values in register_loads indexed by the high fp. Fixed: v8:10307 Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632Reviewed-by:
-
Andreas Haas authored
There exists the pattern in wasm-compiler.cc of allocating a stack slot and filling it with values. This CL introduces a helper function for this pattern. Note that not all cases of this pattern can be changed to use the helper function. In these cases either the size of the stack slot is not statically known, or the stack slot is also used for return values. R=clemensb@chromium.org Bug: v8:10155 Change-Id: I8497a22fed730424561fc32bc1cfa21643341643 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093495Reviewed-by:
-
Clemens Backes authored
We now always tier down to Liftoff when the debugger is enabled, hence we don't need to force Liftoff-only execution in the test. R=thibaudm@chromium.org CC=duongn@microsoft.com Bug: v8:9654 Change-Id: I9b9e21b2ee977b349bb4f5d0e34c6ebf82166cb9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093504Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66630}
-
Nico Hartmann authored
Bug: v8:7790 Change-Id: Ibdfe1c1a1ad2eb082583285493227fb833be4690 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093501 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
