ForInNext can get lowered to a low-level call to the ForInFilter
builtin. We currently type low-level Call nodes simply as Any, leading
to a CHECK failure when the verifier expects a primitive.
This CL fixes the issue simply by manually setting the type as part of
the lowering. An alternative would be to have the Call typing inspect
its input similar to what the JSCall typing does. We can consider this
if we hit the same issue in other cases.
Bug: chromium:1102053
Change-Id: I6682d8cf95c6a3ebaff9c8de677aa20ca676573f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282523
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68688}
After r68405 reduced the default stack size on Arm64 a couple of tests
hit stack limits on the Arm64 android bots. Reduce the argument count
on these tests to avoid this issue.
BUG=chromium:1099623
Change-Id: I8957043b74bd416bb78223599b1a661a4887f54a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280095
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68670}
It seems that the mix of atomic and non-atomic updates to the same
memory location is not working correctly. One fix is changing all memory
updates to be atomic. Another fix is removing the non-atomic access that
happens while the workers are already running (using atomic accesses).
This CL implements the latter.
R=ahaas@chromium.org
Bug: v8:10647, v8:10650
Change-Id: I84b4f3f442b6be3c4ea6e51962a523f443f5e43b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273133
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68603}
An 'arguments' array cannot be allocated in young space when its size
exceeds kMaxRegularHeapObjectSize. In this case the optimizations in
JSCreateLowering::ReduceJSCreateArguments are skipped.
Bug: chromium:1098565
Change-Id: I30fdc78a1eb6e51fcd293785a46c9fd78995da9a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273121
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68585}
The test was taking more than a minute before CL
https://crrev.com/c/2259933. Afterwards, it takes a lot longer, but I
could never reproduce a hang locally.
Let's re-enable and mark SLOW to increase the chance that it runs to
completion. We can then see how much slower it really got.
Also add some output that helps triaging in case it really hangs.
R=ahaas@chromium.org
Bug: v8:9506
Change-Id: I09a935ca0018517d45c6c008a099b8052bc45c47
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2273117
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68582}
This is a reland of f7a1932ef9
There was a wpt test in Chrome that expected the incorrect behavior.
I disable the test in https://crrev.com/c/2264418 so that we can land
the fix here.
Original change's description:
> [wasm] Re-exported globals preserve their identity
>
> V8 fails a recently added spec test that when an imported global get
> re-exported, it should preserve its identity. This CL fixes the behavior
> in V8.
>
> Drive-by change: fix the object printer of globals: a global which
> stores a reference type only has a tagged buffer, a global which stores
> a value type only has an untagged buffer.
>
> R=clemensb@chromium.org
>
> Bug: v8:10556
> Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68513}
Bug: v8:10556
Change-Id: I8e1b08fc9f72dde166cba167e6e320e714796769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264097
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68552}
Similar tests are already skipped on tsan, using the same bug to also
skip this test. Note that it's a slightly different test, but based on
the same "worker-ping-test.js".
TBR=ahaas@chromium.org
Bug: v8:9506
Change-Id: Ie8d0aab5b1fd3ae6c77a65fa04ac4772b2836a1c
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267301
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68548}
This reverts commit f7a1932ef9.
Reason for revert: Breaking wasm wpt tests: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/5408
Original change's description:
> [wasm] Re-exported globals preserve their identity
>
> V8 fails a recently added spec test that when an imported global get
> re-exported, it should preserve its identity. This CL fixes the behavior
> in V8.
>
> Drive-by change: fix the object printer of globals: a global which
> stores a reference type only has a tagged buffer, a global which stores
> a value type only has an untagged buffer.
>
> R=clemensb@chromium.org
>
> Bug: v8:10556
> Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#68513}
TBR=ahaas@chromium.org,clemensb@chromium.org
Change-Id: I06eb1996cafe7d4e93a7e59d21679fea239cf961
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2264956
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68528}
V8 fails a recently added spec test that when an imported global get
re-exported, it should preserve its identity. This CL fixes the behavior
in V8.
Drive-by change: fix the object printer of globals: a global which
stores a reference type only has a tagged buffer, a global which stores
a value type only has an untagged buffer.
R=clemensb@chromium.org
Bug: v8:10556
Change-Id: I949d147fe4395610cfec6cf60082e1faecb23036
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235702
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68513}
With this CL d8 exits with an error code if there is an unhandled
promise rejection, e.g. due tue a failed assertion in a promise. Up
until now these assertions were just ignored.
Bug: v8:10556
Change-Id: I25f20e4be45a2de130562deb15f6a144f0ac976f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238569
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68503}
The IsInBounds function is used in a few different places, when used for
bounds checks on 32-bit platforms, size_t for max_memory_size leads to
incorrect out of bounds accesses as size_t is not guaranteed to be
64-bit on all platforms. Use specific uint32_t, uint64_t methods for
Wasm bounds checking instead of size_t.
Bug: chromium:1080902
Change-Id: I0e21f0a310382c8ed0703c8302200d3352495c13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256858
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68500}
Due to recent spec changes, this CL removes the type immediate of
ref.is_null again. Instead we check if the type of the input parameter
is nullable.
R=jkummerow@chromium.org
Bug: v8:10556
Change-Id: If07d30fe4dd27664be7774422573b2ab2b0dfa20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247654
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68484}
Just a test for now to document how trailing space after async
functions is not removed by SourceRangeAstVisitor.
Bug: v8:10628
Change-Id: I40f0d911c59540ea835c807a2be5b0d1488291d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259852
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68476}
Adjust atomics.wait, atomics.notify semantics for when they are used
with non-shared Wasm memory to mirror the spec change introduced
in: https://github.com/WebAssembly/threads/pull/147. This does not
need to be gated by the flag here, as this will only decode if
the flag is enabled.
Bug: v8:9921
Change-Id: I7f2e018fed6bd131ad4c386def1e838626c28a4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2256863
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68468}
This changes black/white list to block/allow list.
Bug: v8:10619
Change-Id: Id55d72f90891670ca57b62dfeb6b3251025927dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2257228
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68464}
Replace by "consistency check", or "validity check", or more specific
wording as appropriate.
R=ecmziegler@chromium.org
Bug: v8:10619
Change-Id: Ifd7852d8f703d5b784d53671b82d65db15722ede
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2253855
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68440}
Make sure that the workers do not start running before the main thread
told them so by setting the memory to the first element in the sequence.
Otherwise it can happen that the main thread resets the memory after the
workers already started doing their updates, which results in a hang
(see linked bug).
R=marja@chromium.org
Bug: v8:10625
Change-Id: I959018279e0049900d44457b72146bc37a12bcb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2252191
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68429}
When preparsing and detecting a sloppy block function redefinition then
don't mark the variable as assigned to make it consistent with the eager
parser.
Bug: chromium:1053364
Change-Id: Iec7c24db80014bfe73ee41a4f3bb7a41a354cef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241511
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68415}
This subsumes the old behavior of --allow-natives-for-fuzzing under
--fuzzing as well. Both flags are used in a redundant way in fuzz
configs. Only --allow-natives-for-fuzzing wasn't specified as a
required argument, leading to the bug below.
We still need the flag --allow-natives-for-differential-fuzzing
to allow different functions when using differential fuzzing.
Bug: chromium:1094866
Change-Id: I398791779e58ed4d80e896c1cfea343848159212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2246568
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68401}
... for nci code, in which several phases of the compiler are not
active:
LowerJSCreateCatchContext
LowerJSCreateEmptyLiteralObject
LowerJSCreateIterResultObject
LowerJSCreateWithContext
LowerJSGetIterator
LowerJSGetTemplateObject
With this change, the nci variant passes the test suite. Tests
relying on turbofan-specific behavior (e.g. deopts) are skipped.
Bug: v8:8888
Change-Id: I709178241e9b25e7480a39b4fb64bdcf576483be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245604
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68381}
Changes:
- Simplify and generalize ToValueTypeString.
- Fix some error messages in msjunit so that they reflect the underlying
error better.
- Change 'exn' -> 'exnref' to match exception-handling proposal.
Bug: v8:7581
Change-Id: I264f6c9aa598a57f39d5a4d01399af64db83a2b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243214
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68364}
We recently changed uc32 to be an unsigned type, and with the invalid
marker being static_cast<uc32>(-1) this DCHECK no longer holds. After
this CL it expicitly checks for the invalid marker.
Bug: v8:10568,chromium:1094226
Change-Id: Idd9efe055b38387e3e37b132cb786cca130767b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2245592
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68333}
We want to enable the wasm-bigint implementation by default. However,
at the moment there exist several tests which fail when wasm-bigint
gets enabled. With this CL we adjust or delete these tests so that they
pass once wasm-bigint gets enabled. At the same time we disable these
tests for now, and re-enable them in the CL that flips the flag.
R=jkummerow@chromium.org
Bug: v8:7741
Change-Id: I733bfe7ff19e403913b143e6ea86ab13602ab993
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243212
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68328}
The condition was too strong since we never store Smis into
{previously_materialized_objects}.
Bug: chromium:1094132
Change-Id: I680eb7f175f12d3c44882fd8a9eff0d062eda55f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2241517
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68317}
Foozie came up with a mind-boggling example hitting a similarly
mind-boggling bug: object construction (JSObject::New) wants to create
the constructor's function initial map (JSFunction::GetDerivedMap ->
JSFunction::EnsureHasInitialMap). To do so, it calls
JSFunction::CalculateExpectedNofProperties. This harmless sounding
function triggers compilation of the function. Since we're running with
--always-opt, this is an optimizing compilation. Turbofan ends up
depending on the function's "prototype" property, for which it wants to
create the initial map so that it can install the code dependency. That
is, EnsureHasInitialMap is reentered. At this point there is no further
compilation attempt because the bytecode now exists. The initial map is
created and installed on the function, and TF records the code
dependency on that map. When CalculateExpectedNofProperties returns
control to the outer EnsureHasInitialMap, yet another initial map is
created and set on the function, forgetting the previous one and thus
the code dependency.
I'm not sure if this bug can only be observed with --always-opt. The fix
is general.
Bug: chromium:1092011
Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68292}
Previously, for the various customisation points of String builtins
(like String.prototype.replace), we skipped the customisation symbol
lookup (like for Symbol.replace) for Smis.
But, we do need to do the lookup for Smis in case Number.prototype or
Object.prototype have the Symbol. This missing lookup was creating an
observable difference between Smis and HeapNumbers.
Bug: chromium:1092896
Change-Id: I8928d237fa74abeaa2aa81318b8903087c507f0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238030
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68285}
As per the latest update to the 'reference types' wasm proposal, the
nullref type is removed. Following that, all its uses in V8 were also
removed. This CL:
- Removes now dead code referencing nullref.
- Changes names of functions/exceptions containing 'nullref' to 'null'.
- Changes nullref to the corresponding nullable type in some tests.
Bug: v8:7748
Change-Id: I5b4606671d7b24dd48a45a3341e8a1c056fcd1d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238026
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68283}
The reference types wasm proposal dropped all subtyping. Subsequently,
the 'anyref' type was renamed to externref.
This changes all references of the *type* anyref to externref.
Additionally, the flag that permits this extension is renamed to
"reftypes" to mirror the proposal name.
Bug: v8:7748
Change-Id: Icf323f13b9660fd10540e65125af053fca3a03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232941
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68270}
The test takes several minutes, because the {slice} call does thousands
of runtime calls, which again call {ValidateElements} for every single
added element (in debug mode).
Hence this CL skips the test in the slow_path variant.
R=leszeks@chromium.org
Change-Id: I2fbaaf32809ecb34de1f563f34bd65ce8b7ab238
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237628
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68265}
This caused a CHECK failure after my recent CL.
Bug: chromium:1084820, chromium:1092650
Change-Id: Icdc2a755c6b30ad01dccc908e0e5e137fedf8918
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2237145
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68263}
Promise.{all,allSettled,any,race} should check resolve is a function before
opening their iteratable.
PR: https://github.com/tc39/ecma262/pull/1912
PR for Promise.any: https://github.com/tc39/proposal-promise-any/pull/65
This CL includes the following cleanup changes:
- Made it more explicit that the constructor is a Constructor.
- Removed unnecessary nested try blocks (a try can have both a catch and a label).
- Moved commonly used definitions out of promise-race.tq where they don't belong.
- Made the parameter order of PerformPromiseAll match the spec.
Bug: v8:10578
Change-Id: I9deb5d5106db7350a0d0ad52f165ff2469e7074b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232544
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68260}
A previous CL removed the kNoThrow flags from both
SpeculativeBigIntAdd and SpeculativeBigIntSubtract. This introduced a
bug, because the JSTypeHintLowering phase, where these operators are
introduced during inlining, does not support the generation of throwing
operators.
Since these operators always deoptimize in case of an error, instead of
throwing the exception directly, it is safe to mark them as kNoThrow.
Bug: chromium:1091461
No-Try: true
No-Tree-Checks: true
Change-Id: I551616b0c462647574e5af8824d9ed7b3252659d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235113
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68254}
Object materialization did not correctly deal with a mismatch between
current representation of a field value and expected representation.
This is an attempt to repair the situation.
Bug: chromium:1084820
Change-Id: Ib337cbaf5e36a5a616b6a6cb0ddf51018d49b96a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228330
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68231}
Due to recent spec changes, We do not have to check if ref.func
instructions in global declarations only refer to declared functions.
Additionally functions referenced in exports and globals are now
considered declared.
R=ecmziegler@chromium.org
Bug: v8:10556
Change-Id: I79856c7d68155a04eb36769ceed8a58fe62a9f9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228653
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68190}
Speculative BigInt addition fails to throw the expected exception
when called with non-BigInt inputs when the result of the computation
is unused. In paricular, this CL does:
- Remove kNoThrow on speculative BigInt operators
- Fix AddWithFeedback to not lose type feedback if builtin throws
to elide existing deopt loops
- Add handling of TypeCheckKind in RepresentationChanger where this
was previously ignored
Bug: chromium:1073440
Change-Id: I953a5b790fc3b37a6824f0b6546a0488c51fbb3b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228493
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68181}
We use StoreOwnIC to initialize the object after creating a new object
with CreateObjectLiteral. CreateObjectLiteral stores kHoleNaNInt64
to indicate an uninitialized double field. When we actually try
to store a NaN value into that field later using StoreOwnIC, IC avoids
actually storing the new value since the existing value is "same as"
the value we try to write. The float comparison treats all NaNs as
equal. In this particular case, we should actually store the new value
since kHoleNaNInt64 value is used to represent an uninitialized field.
This cl just stores the new value even when the existing value is same
as the new value for double fields. The check is still required to
correctly track const fields.
Bug: chromium:1082293
Change-Id: Ib37061802f2403545cffa6d6fef08be074b0825d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228886
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68167}
