- 17 Oct, 2019 8 commits
-
-
Santiago Aboy Solanes authored
The top bar was being scrolled down since the whole viewpane was scrollable. It will now work in the way the "Dissasembly" tab works: the content is scrollable, but not the pane. This change makes Schedule and Sequence consistent within the other panels. As a drive-by fix, remove some unused constants. Bug: v8:7327, v8:9517 Notry: true Change-Id: I22f8abb6524cb297f43930fc8036b36b7ce59751 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863203 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64347}
-
Sathya Gunasekaran authored
This reverts commit 97ed8b27. Reason for revert: breaks chromium roll https://chromium-review.googlesource.com/c/chromium/src/+/1864878 I bisected it down to this CL here: https://chromium-review.googlesource.com/c/chromium/src/+/1865346/6 https://ci.chromium.org/p/chromium/builders/try/linux-rel/219610 Original change's description: > [regexp] Guarantee an allocated regexp stack > > The regexp stack is used during execution of jitted regexp matcher > code. Previously, the stack was initially not present / nullptr, and > we had to explicitly check for this condition and bail out in builtin > code. > > This CL changes behavior to guarantee a present stack by adding a > statically-allocated area that is used whenever no > dynamically-allocated stack exists. > > Change-Id: I52934425ae72cf0e5d13fab2b9d63d37ca76fcf3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852126 > Auto-Submit: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64326} TBR=jgruber@chromium.org,petermarshall@chromium.org Change-Id: I085b7aebb513fdededda7631b06ff68e5ae5846e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864945Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64346}
-
Igor Sheludko authored
The CL fixes the following builtins: %TypedArray%.prototype.join %TypedArray%.prototype.every %TypedArray%.prototype.find %TypedArray%.prototype.findIndex %TypedArray%.prototype.forEach %TypedArray%.prototype.reduce %TypedArray%.prototype.reduceRight %TypedArray%.prototype.some Bug: v8:4153 Change-Id: I39cdb1801949b1df9d221988b8ed4ed5b2de9341 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864941Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#64345}
-
Clemens Backes authored
"alternates" should be "alternatives". Drive-by: Rename "generate_fn" to "GenerateFn". R=ahaas@chromium.org Change-Id: I09de4678dddcc4a8949dd9589e4dddd0c1c0661c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1866509Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64344}
-
Primiano Tucci authored
This catches up with recent changes. None of them should be relevant for v8. I am doing this mainly because I am going to refactor the proto generator for go/perfetto-libprotobuf and seems worth having a recent last-good checkpoint of perfetto before starting that. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: Icfeb7bda3e01448f4db579a76b2cf8b61626b997 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863202Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Auto-Submit: Primiano Tucci <primiano@chromium.org> Cr-Commit-Position: refs/heads/master@{#64343}
-
Gus Caplan authored
Change-Id: I828450704fdb74bc5ced0f8f85a0546672b4ff9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864571Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64342}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/082f11b..60d20a7 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b9fad2f..8df31ad Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ba97f60..2a0049f TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5e121e66f76fee8a76a3dc17b9b0168ed9ebf0e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865993Reviewed-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@{#64341}
-
Milad Farazmand authored
Port 7d09b270 Original Commit Message: It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ide47f62b5fbfd309a2892fcd934175db7e390a8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864586Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64340}
-
- 16 Oct, 2019 32 commits
-
-
Ng Zhi An authored
Bug: v8:9813 Change-Id: I9ab0d0aafb0a2620a317d99c10f56dbcaa7fdf04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1849206 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#64339}
-
David Benjamin authored
Bug: chromium:1014607 Change-Id: Ifcd1ce17fb1f95965355a4e3f63bdc78fa88042f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865613 Auto-Submit: David Benjamin <davidben@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#64338}
-
Ng Zhi An authored
This introduces 2 new machine operators that are variants of I64x2Splat and I64x2ReplaceLane that takes two int32 operands instead of one i64 operand. Bug: v8:9728 Change-Id: I6675f991e6c56821c84d183dacfda96961c1a708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1841242Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64337}
-
Ng Zhi An authored
TBR=machenbach@chromium.org Bug: v8:9863 Change-Id: I5312e53eca73469b9a77ddb9232535591b8fdcb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1865714Reviewed-by:
Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64336}
-
Clemens Backes authored
The lookahead did not check whether there is actually a byte left to be read. So if the i32 comparison was the last byte in the function body, we would read out of memory. This CL fixes that by introducing a separate {lookahead} method which does the proper bounds check and the lookahead. R=jkummerow@chromium.org Bug: chromium:1014834, v8:9831 Change-Id: I6499ae3f2c57d38a8fcb587b99ae4a4a6c70e426 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864939Reviewed-by: -
Ng Zhi An authored
Bug: v8:9415 Change-Id: I6cd413117fc5c949ed668d2dff2bbfbbc880ebcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863952Reviewed-by:
-
Thibaud Michaud authored
R=clemensb@chromium.org Change-Id: I061ca50c08cfa2bc60e74e4387e3e2933659202b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864655Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#64333}
-
Clemens Backes authored
Instead of spilling x0 and x1 to the stack, use temp registers which should always be available in this situation. This avoids the spill and load. Also, switch from holding {start} and {end} in the register to holding {start} and {count}. This make it easier to correctly initialize the registers. R=joey.gouly@arm.com Bug: v8:9830 Change-Id: I5fc8b8603afaf12fad2ba66cd7a75555ef31bd4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859618 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
Seth Brenith authored
This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Clemens Backes authored
Most comparisons are followed by a br_if instruction. This CL detects that for i32 comparisons and folds them with a following br_if, avoiding to materialize the result of the comparison as 0 or 1 in a register. This saves three out of the five instructions generated for this pattern before. Plus some drive-by cleanup. R=jkummerow@chromium.org Bug: v8:9831 Change-Id: I7bed47f2523b60b2bf301f074fe3132aea9a0636 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862561 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I2eb419bbfbea81d58b1c13e527af1728d84c4092 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864656Reviewed-by:
-
Joshua Litt authored
Bug: v8:9838 Change-Id: I0675b124b2377ff32cb8ae7bbc5eac8ce60314ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1854011 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Mainly updating '@types/d3' Change-Id: Ia3df5f4c29c4bf7cfe167a8b03ab20a2ad532cde Notry: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863195Reviewed-by:
-
Jakob Gruber authored
The regexp stack is used during execution of jitted regexp matcher code. Previously, the stack was initially not present / nullptr, and we had to explicitly check for this condition and bail out in builtin code. This CL changes behavior to guarantee a present stack by adding a statically-allocated area that is used whenever no dynamically-allocated stack exists. Change-Id: I52934425ae72cf0e5d13fab2b9d63d37ca76fcf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852126 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
They have no function and are confusing to first time users, who think that you have to click that to upload a file. It would be better to not add them at all, but the logic searches for 'li.last-tab' and it seems hard to unravel. Bug: v8:7327 Notry: true Change-Id: I07e903947e15ccc0d5431488a4c4fcded999f91d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863194 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Victor Gomes authored
Change-Id: Iaee4c09124d77aa47fc968bb9e508af587d9e3ed Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864830 Auto-Submit: Victor Gomes <victorgomes@google.com> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64324}
-
Michael Starzinger authored
This extends existing table support to be able to store 'exnref' in addition to 'anyref' types. Tools can use this to maintain data structures for exception packages. R=ahaas@chromium.org TEST=mjsunit/wasm/exceptions-anyref BUG=v8:8091 Change-Id: Iccbcfdc328db81a366921bcdd98c2256f66e7fc8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781046 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
-
Michael Starzinger authored
With the recent removal of the --wasm-shared-code flag, it became effectively impossible to turn off this flag. Hence its functionality became mandatory and the ability to turn off sharing of {WasmEngine} process-wide has to be removed as well. R=clemensb@chromium.org Change-Id: I7c25e909e49134a226d6a9fe9c42f0ecd9d02a69 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864935 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: -
Clemens Backes authored
It turns out that because we are *subtracting* from fp, we need to *subtract less* to get a higher address. Who knew. R=jkummerow@chromium.org Bug: v8:9830, chromium:1014798 Change-Id: I5b9782dd0be27f4c3efbd306ec6c3450b249cb55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864933Reviewed-by:
-
Sathya Gunasekaran authored
Updates CSA::TryToIntptr to handle array indices that are less than INT_MAX which allows to handle string keys in the ICs. Updates ICs to go monomorphic for string keys that are array indices. Updates Turbofan to handle array indices when lowering element access. Change-Id: Ibdde20130e075d0d645ab4a8266a968335eaad84 Bug: v8:9449 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813018Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64320}
-
Santiago Aboy Solanes authored
It's already on the 'Graph view' section and fits better there. Bug: v8:7327 Notry: true Change-Id: Ie7024f1db02c5cf6b451f5f5401fd01195996848 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863192 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Joshua Litt authored
This cl modifies RegExp.prototype.matchAll to throw on non-global regexps. Relevant pull request: https://github.com/tc39/ecma262/pull/1716 Bug: v8:9800 Change-Id: Ie963c1c00441f1c4e2b975c3bab77cca902c7ebc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846067Reviewed-by:
-
Jakob Kummerow authored
for "entries", i.e. indices into the backing store (as opposed to "public indices" going into the hash function). This improves consistency and compiler-enforced type safety; no change in behavior is intended. Change-Id: I25e57e3ddcf18a406e2dfbd66786b6980c4e9615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852768 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64317}
-
Sathya Gunasekaran authored
This reverts commit c7c47c68. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by:
-
Mu Tao authored
Port a8cdda99 Original Commit Message: WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=xwafish@gmail.com Change-Id: Id65b6d36beadcba0d3f3726bb6559bb316cb212e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862830 Auto-Submit: Mu Tao <pamilty@gmail.com> Reviewed-by:
-
Toon Verwaest authored
This is a reland of f05bae1e Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Matheus Marchini authored
Symbol and *String classes are now declared on Torque with generateCppClass, which means they don't use macro accessors anymore. As such, the gen-postmortem-metadata script is not able to automatically detect fields for those classes. Define metadata for those fields manually for now. In the future we might want to generate it from Torque for consistency. Also renamed a few *String fields metadata to match the expected format (className__fieldName__fieldType). For more context: https://github.com/nodejs/llnode/issues/287#issuecomment-539707117. R=bmeurer@chromium.org, hpayer@chromium.org, verwaest@chromium.org, yangguo@chromium.org Change-Id: I82fe8315cdbfd1b8c64c6a8d5dc011b1edaec39e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847783Reviewed-by:
-
Thibaud Michaud authored
This prevents the branch table iterator's has_next() method to trigger a DCHECK when the decoder fails before the end of table decoding. R=clemensb@chromium.org Change-Id: I2258886501b77cd4c8fe98bc8a4ed0b66fb23066 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864931Reviewed-by:
-
Liviu Rau authored
Using test runner with option --progress=ci can generate output timeouts in an actual CI environment. To avoid that we gonna write a timestamp in the standard output at every minute. Bug: v8:9146 Change-Id: Id2f05530956b01d9b07809e509cd0cefc0be54b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863196 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64311}
-
Clemens Backes authored
DCHECKs are not really special, they just create a non-constexpr path within an otherwise constexpr function. Since C++14, this is allowed. Unfortunately, gcc only supports this since version 6, but we still need to support gcc 5. R=ulan@chromium.org Change-Id: If74486144abafa5bbdcdbb9a567ee9295ac4cfc7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862568Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64310}
-
Thibaud Michaud authored
R=ahaas@chromium.org Change-Id: I0405abbd8fc047653758ac41d185bf0f44e33d09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859617 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: I5b5ada546e1d0b9d42ea8f7278671bf2b128bef8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862570Reviewed-by:
-
