Also drive-by adds a test for toSpliced on an empty array.

Bug: chromium:1367651, v8:12764
Change-Id: I59ff19ef73dd6c5ea972dc6f39f1968858099ef8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3919870
Commit-Queue: Adam Klein <adamk@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83441}

Bug: v8:13328, v8:12764
Change-Id: Idd079b6eaa7e47b0cbe57840e9cd185c2abfe7dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913771Reviewed-by: Adam Klein <adamk@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83440}

It is possible, though unlikely, that V8 will deserialize code cache
data, decide to merge that new data with an existing script from the
Isolate compilation cache, and subsequently do nothing in the background
portion of the merge (make no heap changes, and request no follow-up
changes on the main thread). In this case, the most optimal outcome is
to reuse the script from the Isolate compilation cache, not to use the
newly deserialized script.

CodeSerializer::FinishOffThreadDeserialize uses
BackgroundMergeTask::HasPendingForegroundWork to determine whether it
should complete the merge and use the Script from the compilation cache
or complete the deserialization and use the newly deserialized Script.
This change updates HasPendingForegroundWork so that it will return true
even if the merge was a no-op.

Bug: v8:12808
Change-Id: I08fcb814e797218e5be2b4ce4f45bd4e0637ec80
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916270
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83439}

The current Array#push reduction supports some amount of non-redundant
homogeneous from its receiver maps, and unifies polymorphism by
generating a push implementation per unique receiver elements kind,
rather than per receiver map. It does this by dynamically reading off
the receiver's elements kind, and branching on it.

Reading off the receiver's elements kind dynamically is a bit of a waste
though, since we already know the small subset of maps that are possible
at this point, and have probably emitted diamonds for checking those
maps which can't be merged with the dynamic elements kind lookup.

In this patch, this code is changed in two major ways:

  1. We perform comparisons on the receiver map, rather than the
     receiver elements kind, and dispatch to the per-elements kind
     implementation after that check.

  2. We allow the Smi path to fallthrough into the Object elements path,
     once its Smi checks complete, to avoid generating distinct but
     identical grow-and-set code for both PACKED_ELEMENTS and
     PACKED_SMI_ELEMENTS.

Change-Id: Ie7764339a0220cb30aee0592553e0dc98539ac79
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3912765Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83438}

Those operators are not eliminable and need different properties than
the rest of loads/stores.

Bug: v8:12783
Change-Id: I7cd478fa827589612ca5d7628c628c09f3f4a3a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909361
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83437}

Make Load/StoreHandler printing a bit more robust against unexpected
values, which we may have missed in the printing definition (or the
value is corrupt, or the caller of the print is passing the wrong value
in) -- for printing like this it's better to be able to not crash on
invalid state.

Change-Id: Ibf5c2064d6aac3da1ac6c19469fe31d5f761b6dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918710
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83436}

This CL decouples the Wasm GC JS interop from the experimental
string <-> array conversions as the interop is now enabled by
default, still there are some issues discovered with the
conversions.
The functions are fixed via https://chromium-review.googlesource.com/c/v8/v8/+/3916633.

Bug: chromium:1366881
Change-Id: I27730523a51d24a7ea18199e1668e8c76f0bcb4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916088Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83435}

This introduces a new DirectHandle class with a deliberately similar API
to Handle. It uses an API that uses identical method names for symmetry,
but with an address field containing a direct pointer to JS heap objects
(or SMI).

Direct handles are experimental and can be enabled with the
v8_enable_conservative_stack_scanning gn option. The motivation for them
is described in the design doc [1].

[1]: https://docs.google.com/document/d/1uRGYQM76vk1fc_aDqDH3pm2qhaJtnK2oyzeVng4cS6I/

Bug: v8:13270
Change-Id: I0a6e0581adb5fa3b420efec3ba2b6d609d945c52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3820483
Commit-Queue: Jake Hughes <jh@jakehughes.uk>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83434}

This CL fixes the build with neon intrinsics using clang-cl.
Seems it doesn't need to apply MSVC workaround for uint32x4_t and uint64x2_t.

Bug: v8:13333
Change-Id: Ic053a5c344de492458f9da749d81808775491dcf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916643Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83433}

It's possible the path into resumable loop looks dead, while the loop
body itself is resumable and is being optimized due to an active
generator running the loop. By reviving resumable loop headers we have a
chance to properly optimize such generators (and avoid deoptimizing them
prematurely).

Bug: v8:7700
Change-Id: Icf5dadba17a7fd38409193e1e3f702f108a5639e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918093
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83432}

Drive-by: dtype and stype are removed from SIMD_UNOP_LIST,
toSimd() requires them to all be of type `fp`.

Change-Id: Ifdfe187e2b143fb8fa785c44344bea38ea7e10f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916553
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#83431}

ref.cast_nop is used for internal testing only.
0xfb48 will become ref.test null.

Bug: v8:7748
Change-Id: Iaee762dd97a993a361edddf656090210876178a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913205Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83430}

Non-well-behaved test cases may pass too few arguments. The builtins
shouldn't attempt to inspect arguments that aren't there.
Not bothering with a regression test because these experimental
builtins are probably short-lived at this point anyway.

Fixed: chromium:1366881
Change-Id: Ifee8929c6a97539eac7609c64082d66cd53cec89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916633
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83429}

Change-Id: I947359645587f63fad4413e340177027e42812d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916642
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83428}

... when "return" property is added to respective iterator or might be
added somewhere up the prototype chain.

According to the iterator protocol the "return" callback must be
called when iteration is aborted in the middle.

Bug: chromium:1357318
Change-Id: I36d81b90cfd40e417136ab97ec53ad7054f4df77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916630Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83427}

I.e., implement the TurboFan handler for the FindNonDefaultConstructor
bytecode.

Bug: v8:13091
Change-Id: I021b5d24817b47e3ce86cc1ac1377056cfd5e2a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3885892
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83426}

Similar to existing v8.compile trace events for Turbofan. Also, augment
both with flow events.

Bug: v8:7700
Change-Id: I1de96120ce1da98fe3ea1670b5f52cc7d65929cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3918090
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83425}

The GraphAssemblerLabel VarCount template parameter now can have a
marker value ~0 which is marker for it being dynamic sized -- this means
that a bit of template magic turns its std::arrays into std::vectors.
Merging GraphAssemblerLabels works by duck-typing access to these
arrays/vectors.

These dynamic GraphAssemblerLabels are created whenever a single

GraphAssemblerLabels being created when instead a list of values
convertible to MachineRepresentation is passed in. Passing anything else
will result in a GraphAssemblerLabel with marker value ~1, which is
considered "invalid" and will give a compilation error down the line.

std: :vector is passed into MakeLabel, with the static
Change-Id: I833bdedac2f8e26fcc88aa59dd67b7e4b1c4296d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913349
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83424}

Bug: v8:13331
No-Try: true
Change-Id: Id9fcee30d955f3668f8c2bfbb01757dbd5b54337
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916641Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Almothana Athamneh <almuthanna@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83423}

Change-Id: Ia3ef956926b54add138936e3e7d03a0faa457ff9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913127Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83422}

When performing full GC on a shared space isolate, the GC also needs
to visit OLD_TO_SHARED slots in client isolates and update pointers.

Bug: v8:13267
Change-Id: Ida48c666dce8f5ed703a6920ad007add9235d64a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913347
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83421}

Bug: v8:12783
Change-Id: Ia4aaf245428dd63be09a33bfb684f0573f6b9296
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913084Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83420}

Collect feedback for BigInt64 in interpreter and change the runtime
for BigInt64 addition.

Bug: v8:9407
Change-Id: Ic69ba2c1f5ada998ac5ee3279e8296efe084d600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3909809
Commit-Queue: Qifan Pan <panq@google.com>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83419}

See also Turbofan's JSContextSpecialization reducer.

For all context loads and stores, this CL implements:

1) depth reduction through graph walks (even without FCS)
2) conversion from the context node to a heap constant
3) if possible, conversion of a load of an immutable context slot load
   to a heap constant

Bug: v8:7700
Change-Id: Ie4d1acd0ff206f25dd5373a860d23b006a31dcee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3904914Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83418}

This reverts commit f08547af.

Reason for revert: Causes failures due to virtual address space
exhaustion inside the sandbox.

Original change's description:
> [sandbox] Improve the default ArrayBufferAllocator for the sandbox
>
> Rather than using a page allocator and rounding all allocation request
> sizes up to the next multiple of the OS page size, we now use a
> base::RegionAllocator with a "page size" of 128 as a compromise between
> the number of regions it needs to manage and the amount of wasted memory
> due to allocations being rounded up to a multiple of that page size.
> While this is still not as performant as a "real" allocator, it does
> noticeably improve performance when allocating lots of ArrayBuffers.
>
> Bug: chromium:1340224
> Change-Id: I56d1ab066ba55710864bdad048fb620078b2d8c2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913346
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#83396}

Bug: chromium:1340224
Change-Id: I3e3cc18c0e75cac586b7f014a75df1028bbfa86f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916637
Commit-Queue: Samuel Groß <saelo@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83417}

There is no need for ClientHeapVerifier anymore since we can simply
invoke full verification for all client heaps.

Bug: v8:13267
Change-Id: Ic72744aed09569f2e3e61bb3d6c889d2a7ad4de3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913030
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83416}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/60deb86..f87b9ff

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/b79692f..15fa3e7

Rolling v8/buildtools/third_party/libc++/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+log/a4dc7f1..4d2c483

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I976f25d255f7f0f346a29de870b24f9b974a3d71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3917710
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83415}

In wasm-spec, the shift amount will modulo 32 or 64.

Change-Id: I98d003dfd8b73d0d3eb1a022942d7b138d29fdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3912629Reviewed-by: ji qiu <qiuji@iscas.ac.cn>
Commit-Queue: ji qiu <qiuji@iscas.ac.cn>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#83414}

Bug: v8:13322
Change-Id: I0826175aeb47c07a7b53792d4c271a095b44e322
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3915225Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83413}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d2ff521..60deb86

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/40b472e..209fff0

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I72143dcc8a33f25a99cec34dfce6091684bcc2cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3914622
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83412}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/bc5a8a1..d2ff521

R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com

Change-Id: I6c275f6f326f89e5181fc5ec12feb80a40159197
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3914620
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Bot-Commit: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#83411}

Sync to the spec/calendar.html changes in
https://github.com/tc39/proposal-temporal/pull/2377
to change the order of calling ToTemporalOverflow.
This cl only cover the ISO8601 part, the the intl part of the PR
is not yet implemented and will be handle when e implemenet them.

Spec text:
https://tc39.es/proposal-temporal/#sec-temporal-isodatefromfields
https://tc39.es/proposal-temporal/#sec-temporal-isoyearmonthfromfields
https://tc39.es/proposal-temporal/#sec-temporal-isomonthdayfromfields

Bug: v8:11544
Change-Id: Ia4386d460dc45b0b377a483c6f4793da4cbd7c20
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3903223
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83410}

Sync with https://github.com/tc39/proposal-temporal/pull/2394
to fix  TemporalCalendarString ambiguity issues


Spec text:
https://tc39.es/proposal-temporal/#sec-temporal-parsetemporalcalendarstring
https://tc39.es/proposal-temporal/#sec-temporal-totemporalcalendar

Bug: v8:11544
Change-Id: I31d0255e55d1a432681fd060cf4f841cb1479480
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3901196Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83409}

Bug: chromium:1367107, v8:12764
Change-Id: I0d07fc49eb68b1fa1a22635411e9b6b79ef2e2d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3915483Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83408}

MSVC does not support inline assembly (clang-cl does).

Those two functions needs to be implemented using C++ only. Implemented
a version for MSVC only, based on an intrinsic (that guarantees load,
even with optimization) available for any architecture.

Bug: v8:13312
Change-Id: I3aa4eac03c099535c5d3a9a40221bd5f8bbcb0d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913036Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83407}

MSVC is confused by initializer list and default parameter, and reports
an ambiguous call.

test/cctest/test-assembler-arm64.cc(12208): error C2668: 'v8::internal::Clobber': ambiguous call to overloaded function
test-utils-arm64.h(251): note: could be 'void v8::internal::Clobber(v8::internal::MacroAssembler *,v8::internal::CPURegList)'
test-utils-arm64.h(241): note: or       'void v8::internal::Clobber(v8::internal::MacroAssembler *,v8::internal::RegList,const uint64_t)'

Solution is to construct with explicit type.

Bug: v8:13312
Change-Id: I66f5ba48bcdf6eb30035beaf7214a3d26fc9f18b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913034Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83406}

Array#with and TypedArray#with adapt their arguments because they have a
fixed arity of 2. Builtins that adapt arguments shouldn't use
...arguments in Torque, which results in a "don't adapt" sentinel to be
generated, resulting in incorrect frame size computation.

Bug: v8:12764, chromium:1367133
Change-Id: I81c1ef2cdef25d049fa0b8effcb2a953c2a9846b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3915939
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83405}

This compilation error was found by NodeJS when updating V8:
https://github.com/nodejs/node-v8/issues/240

MSVC reports an error with "too many initializer" for type uint32x4_t.

---

Under gcc/clang, this is a typedef to a builtin type.

For MSVC, it is a typedef to this union:
typedef union __n128
{
     unsigned __int64   n128_u64[2];
     unsigned __int32   n128_u32[4];
     ...
} __n128;

C++ mandates that only first member of union can be initialized at
declaration. Thus, it can only be initialized with {uint64_t, uint64_t}.

VS people proposed to use designated initializer instead:
var = {.n128_u32={1, 2, 3, 8}}
https://developercommunity.visualstudio.com/t/error-c2078-too-many-initializers-when-using-arm-n/402911
But, you need to use /std:c++20 for this, which is not the case in v8.

---

Thus, the only solution is to implement a hack specifically for MSVC,
where you build two uint64, from four uint32.

---------------------------------------

Once solved, another error is reported:
templated function extract_first_nonzero_index is specialized twice.

This is because, with MSVC, uint32x4_t and uint64x2_t are typedef to the
same __n128 union. The fix is to drop templates, and use explicit
function names instead.

Bug: v8:13312
Change-Id: I231d8cf01c05af01af319d56d5666c415f8b989b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913035Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83404}

Bug: v8:12764, chromium:1367136
Change-Id: Ia73f507bf480035d883be1bb5189a5b464327d29
Fixed: chromium:1367136
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3916281
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83403}

clang/clang-cl compiled happily (probably included transitively this
header), but not MSVC.

Bug: v8:13312

Change-Id: I69b6c15f76d8ef13e4fac33f733717429ba96f71
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3913033Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83402}