We used to only mark top-level SFIs with the 'deserialized' bit.
Now we do it for every SFI that has cached code. This is the
first step to surface caching information in the future.
R=cbruni@chromium.org
Bug: chromium:769166
Change-Id: I12f21511419ce54fd07a2cc277a65866660c366a
Reviewed-on: https://chromium-review.googlesource.com/686715
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48184}
There was an issue with passing float32 parameters, if the value was
spilled on the stack and passed as stack parameter.
First, we sometimes reduced the stack pointer by 8 bytes instead of 4,
and second, there was a mismatch between movsd and movss.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: Ia884df369ddd95adeff3733f9715f589996f0b65
Also-By: ahaas@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/684738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48181}
This reverts commit 9d3c4b4b91.
Reason for revert: Breaks cctest/test-debug/NoBreakWhenBootstrapping in no-snap mode.
Original change's description:
> [turbofan] Implement lowering of {JSCreateClosure}.
>
> This adds support for inline allocation of {JSFunction} objects as part
> of closures instantiation for {JSCreateClosure} nodes. The lowering is
> limited to instantiation sites which have already seen more than one
> previous instantiation, this avoids the need to increment the respective
> counter.
>
> R=jarin@chromium.org
>
> Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
> Reviewed-on: https://chromium-review.googlesource.com/594287
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48176}
TBR=mstarzinger@chromium.org,jarin@chromium.org
Change-Id: Id52281f6a3c0b7c2603053ecf002777d5b0d6f1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/686534
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48178}
This adds support for inline allocation of {JSFunction} objects as part
of closures instantiation for {JSCreateClosure} nodes. The lowering is
limited to instantiation sites which have already seen more than one
previous instantiation, this avoids the need to increment the respective
counter.
R=jarin@chromium.org
Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
Reviewed-on: https://chromium-review.googlesource.com/594287
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48176}
- Move things to conversions.cc that don't need to be in headers
- Turn InternalStringToInt into a subclassable helper class
so we can re-use it for BigInt.parseInt
- Bonus: play a round of IWYU with all the .cc files who thought that
#including conversions-inl.h would give them nice Unicode things
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I64022543a9b83002e2b78416c7e87b40a1a016e6
Reviewed-on: https://chromium-review.googlesource.com/673725
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48174}
This CL teaches the respective bytecode handlers and standalone stubs
about BigInts, and collects "kBigInt" feedback for them. However,
Turbofan does not yet care about such feedback, so it is simply converted
to "any" for now (making TF emit stub calls for BigInt operations).
Bug: v8:6791
Change-Id: I6440c108ccd79058d77adc2a6041251db9d5f81d
Reviewed-on: https://chromium-review.googlesource.com/683758
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48173}
This fixes the signature of "Math.abs" from "(signed) -> signed" to
"(signed) -> unsigned" and hence fixes cases where the absolute value
would overflow the range of signed 32-bit values. This is in sync with
spec erratas (and ECMAScript semantics).
Note that this also switches the underlying implementation of the above
absolute value function to a branch-free version.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-3
BUG=v8:6838
Change-Id: Ib13b7ecd336ae386cbde7c574e727bf52f841e00
Reviewed-on: https://chromium-review.googlesource.com/684181
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48169}
Follow up to https://chromium-review.googlesource.com/671020
We still didn't return the correct amount of invalid characters, according to
the Encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder ), when we
saw a byte sequence which was as start of an overlong / invalid sequence, but
there weren't enough continuation bytes.
A more rigorous test will follow in
https://chromium-review.googlesource.com/c/v8/v8/+/681217
BUG=chromium:765608
Change-Id: I535670edc14d3bae144e5a9ca373f12eec78a934
Reviewed-on: https://chromium-review.googlesource.com/681674
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48165}
This is a reland of 629406d1e9
Original change's description:
> [snapshot] include version string in the startup snapshot.
>
> This is to easier diagnose build issues involving the snapshot.
> Sample error message for mismatching snapshot:
>
> #
> # Fatal error in ../../src/snapshot/snapshot-common.cc, line 286
> # Version mismatch between V8 binary and snapshot.
> # V8 binary version: 6.3.1 (candidate)
> # Snapshot version: 6.3.0 (candidate)
> # The snapshot consists of 2820444 bytes and contains 1 contexts.
> #
>
>
> R=machenbach@chromium.org
>
> Bug: chromium:764327
> Change-Id: Icdc7aeac77819b113985b424feda814a072d5406
> Reviewed-on: https://chromium-review.googlesource.com/684295
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48161}
Bug: chromium:764327
Change-Id: I3721689824e0a6909eede86d0829dc258ae40c4d
Reviewed-on: https://chromium-review.googlesource.com/684494
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48164}
- Add kProduceExhaustiveCodeCache to v8::ScriptCompiler::CompileOptions
to request eager compilation to add as much as possible to the code
cache for the script.
- Repurpose ParseInfo::kLazy flag.
- Remove ParseInfo::kDebug flag.
- Remove --serialize-toplevel as it has become obsolete.
R=marja@chromium.org
Bug: chromium:768705
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ife14f7a1d1c02e525f0b9dbfd2452013d67c7167
Reviewed-on: https://chromium-review.googlesource.com/684019
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48160}
In the test-run-wasm and test-run-wasm-64 cctests it is not possible to
call runtime functions. To test traps in these cctests we therefore
replace the runtime call with a call to a c-callback, followed by a
return. This CL fixes the problem that the return did not clean up stack
parameters.
This CL unblocks
https://chromium-review.googlesource.com/c/v8/v8/+/671008. Originally I
wanted to mitigate the problem in that CL by defining an additional
parameter register for arm. However, adding additional parameter
registers lets other tests fail.
R=titzer@chromium.org, rodolph.perfetta@arm.comCC=enricobacis@google.com
Bug: v8:6858
Change-Id: Ia8de73b70a0677ca4d379ed5b16272faee92a78d
Reviewed-on: https://chromium-review.googlesource.com/684017
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48158}
This caused trouble for my downstream CI tests, even though it builds
successfully in the canonical v8 tree. To be investigated properly
later.
Bug: chromium:746958
Change-Id: I180a5ecc51051e4eb6617180ccba787ff80bcf45
Reviewed-on: https://chromium-review.googlesource.com/682695
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48151}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
There is no jumbo_executable target atm, so split the cctest v8_executable
target into cctest and cctest_sources.
Bug: chromium:746958
Change-Id: Iec0956234d026039c4d29921170dd2f0955222ca
Reviewed-on: https://chromium-review.googlesource.com/680575
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48147}
Previously, we would blindly register new handler data, leading to us leaking
the old handler data. This meant we could then end up with overlapping handler
data where the instruction offset and landing pads didn't line up right.
Bug: v8:6841
Change-Id: Iedcd75925b8d9d59c8f9accf288cae954fdc568f
Reviewed-on: https://chromium-review.googlesource.com/677632
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48144}
This fixes the signatures of "Math.ceil", "Math.floor" and "Math.sqrt"
from "(float?) -> float" to "(float?) -> floatish" which avoids using a
resulting float value without coercing the value via explicit "fround"
annotations. This ensures proper ECMAScript semantics are maintained.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-2
BUG=v8:6838
Change-Id: Ib5821641265bc862184adb270e8dbf8c703fdfb0
Reviewed-on: https://chromium-review.googlesource.com/681694
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48142}
This is a reland of ec952aaa68.
Included is a fix that ensures that top_on_previous_step_ is cleared when we
release a page.
Original change's description:
> Reland "[profiler] proper observation of old space inline allocations"
>
> This is a reland of 672a41c3ca
> Original change's description:
> > [profiler] proper observation of old space inline allocations
> >
> > Bug: chromium:633920
> > Change-Id: I9a2f4a89f6b9c0f63cb3b166b06a88a12f0a203c
> > Reviewed-on: https://chromium-review.googlesource.com/631696
> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48043}
>
> Bug: chromium:633920
> Change-Id: I6fe743d31b8ff26f3858488d4c014c62d3c85add
> Reviewed-on: https://chromium-review.googlesource.com/671127
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
> Cr-Commit-Position: refs/heads/master@{#48085}
Bug: chromium:633920
Change-Id: I8a0dcc4eaffc1f1d3ac5b3f8d344001cdae36606
Reviewed-on: https://chromium-review.googlesource.com/677407
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#48141}
When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.
The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from
createEmptyArrayLiteral: 1846 ms.
createShallowArrayLiteral: 1868 ms.
createShallowObjectLiteral: 2246 ms.
to
createEmptyArrayLiteral: 1175 ms.
createShallowArrayLiteral: 1187 ms.
createShallowObjectLiteral: 1195 ms.
with this CL, so up to 2x faster now.
Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.
Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
This fixes the signature of "Math.min" and "Math.max" for integer values
from "(int, int...) -> signed" to "(signed, signed..) -> signed" which
properly distinguishes signed from unsigned values now. This is in sync
with the spec errata (and ECMAScript semantics).
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-1
BUG=v8:6838
Change-Id: Id72836513dd86e93472a22cf1ac2e2d382ed4f23
Reviewed-on: https://chromium-review.googlesource.com/681357
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48139}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=yangguo@chromium.org
Bug: v8:6837
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112
Reviewed-on: https://chromium-review.googlesource.com/681374
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48138}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=ulan@chromium.org
Bug: v8:6837
Change-Id: I8d900f3c703dea6ee3bcc225a1d2754e91666b9d
Reviewed-on: https://chromium-review.googlesource.com/671047
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48136}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=jarin@chromium.org
Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
Track whether the async arrow func parameter list was simple or not; the
information is already there, we just didn't pipe it through correctly. It's
needed by PreParser so that it can create the correct Scope structure.
Implementation notes:
- I could've used async_classifier for transmitting the "is_simple" bit, but I
made it explicit (it would be unnecessary to use ExpressionClassifier for
this, as we're not classifying any expressions) instead.
- I'm also moving work (setting parameter_list.is_simple) from Parser to
ParserBase, and adding a DCHECK in Parser to assert that the work was indeed
already done.
BUG=v8:5516,chromium:765532
Change-Id: Iacf91b150d1b57996544b5e64baa7d91ac134445
Reviewed-on: https://chromium-review.googlesource.com/674695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48132}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
- Moves GetRandomMmapAddr from platform to v8::internal allocation
primitives, in preparation for delegating this to the embedder.
- Adds hint parameters to OS functions that used to use this function.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
Reviewed-on: https://chromium-review.googlesource.com/677777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48124}
TurboAssembler::CallRecordWriteStub contains info that could be used to
conditionally skip generational write barrier or skip saving float-point
registers. This commits uses those info in RecordWrite stub.
Bug: chromium:749486
Change-Id: I41c9a593473e1f8863a09887fd2ce917f1d4fb3b
Reviewed-on: https://chromium-review.googlesource.com/672527
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48123}
This change enables moving the WasmToJSWrapper off the GCed heap
R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Bug:
Change-Id: I1ea8810fa7b71bcb2a80a1390742db64872c5bb1
Reviewed-on: https://chromium-review.googlesource.com/665977
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48118}
This is a reland of c6b153fd69
Original change's description:
> [cctest] Add fuzz tests for generating parallel moves.
>
> These new tests are somewhat similar to the existing gap resolver tests except
> we use the code generator and eventually run the generated code. The main idea
> is to cover cases that are difficult to hit, such as move from/to slots which
> are out of range of loads and stores, but may happen nonetheless.
>
> At this time, the tests only make sure the code generator actually generated
> some code, and that this code runs. In the future, it would be great to also
> check that the moves were actually performed.
>
> Bug: v8:6553
> Change-Id: I089a25fa05b3a20649658bb8952926ab11f91d68
> Reviewed-on: https://chromium-review.googlesource.com/574850
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47733}
Bug: v8:6553
Change-Id: Ia3eac9d7e6a23e2f6fea839b71d460cb7ad6ff6e
Reviewed-on: https://chromium-review.googlesource.com/645868
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48115}
This is a reland of f2cd10db14
Original change's description:
> Reland "[Memory] Move VirtualMemory out of base:: platform."
>
> This is a reland of 4dd293d922
> Original change's description:
> > [Memory] Move VirtualMemory out of base:: platform.
> >
> > - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> > - Makes VirtualMemory platform-independent by moving internals to new
> > OS:: static methods, for each platform.
> >
> > This will make it easier to delegate memory management in VirtualMemory
> > to V8::Platform, so that embedders like Blink can override it. We can't
> > depend on V8::Platform in base/platform.
> >
> > Bug: chromium:756050
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> > Reviewed-on: https://chromium-review.googlesource.com/653214
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48048}
>
> Bug: chromium:756050
> Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/671125
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48084}
Bug: chromium:756050
Change-Id: Ie596730b5cefc38137cab7fc1f76613f5af7b825
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/675283
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48113}
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.
This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.
Also, lots of unit tests.
R=ishell@chromium.org
Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
This fix is two-fold:
1) Incremental UTF-8 decoding: Unify incorrect UTF-8 handling between V8 and
Blink.
Incremental UTF-8 decoding used to allow some overlong sequences / invalid code
points which Blink treated as errors. This caused the decoder and the Blink
UTF-8 decoder to produce a different number of bytes, resulting in random
failures when scripts were streamed (especially, this was detected by the
skipping inner functions feature which adds CHECKs against expected function
positions).
2) Non-incremental UTF-8 decoding: return the correct amount of invalid characters.
According to the encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder
), the first byte of an overlong sequence / invalid code point generates an
invalid character, and the rest of the bytes are not processed (i.e., pushed
back to the byte stream). When they're handled, they will look like lonely
continuation bytes, and will generate an invalid character each.
As a result, an overlong 4-byte sequence should generate 4 invalid characters
(not 1).
This is a potentially breaking change, since the (non-incremental) UTF-8
decoding is exposed via the API (String::NewFromUtf8). The behavioral difference
happens when the client is passing in invalid UTF-8 (containing overlong /
surrogate sequences).
However, afaict, this doesn't change the semantics of any JavaScript program:
according to the ECMAScript spec, the program is a sequence of Unicode code
points, and there's no way to invoke the UTF-8 decoding functionalities from
inside JavaScript. Though, this changes the behavior of d8 when decoding source
files which are invalid UTF-8.
This doesn't change anything related to URI decoding (it already throws
exceptions for overlong sequences / invalid code points).
BUG: chromium:765608, chromium:758236, v8:5516
Bug:
Change-Id: Ib029f6a8e87186794b092e4e8af32d01cee3ada0
Reviewed-on: https://chromium-review.googlesource.com/671020
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48105}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
Along with BigInt.prototype. Their functions only have skeleton
implementations. The purpose of this change is to make it easier
to gradually increase test coverage (e.g. for toString(radix)).
Of course this is still behind the --harmony-bigint flag.
Bug: v8:6791
Change-Id: Ic307fd9165c56ac782fba18d648ce893daaa718f
Reviewed-on: https://chromium-review.googlesource.com/671209
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48094}
There is no support to emulate atomic WASM operations on big-endian
platforms, since this would require bit swapping as a part of atomic
operations. Therefore, cctest/test-run-wasm-atomics/* will be skipped.
TEST=cctest/test-run-wasm-atomics/*
BUG=
Change-Id: I1a8b085f816f615011788092e6fc8a8390678382
Reviewed-on: https://chromium-review.googlesource.com/671010
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48093}
This fixes a few leftovers where we use WASM_EXEC_TEST, but then
unconditionally execute the compiled code, and also changes more tests
to use WASM_EXEC_TEST, hence run in both the interpreter and compiled
code.
Once we have land the baseline compiler, those tests will also execute
in baseline compilation mode.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I79598df21a7538934306e01ca6593f05afe19ed3
Reviewed-on: https://chromium-review.googlesource.com/672528
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48091}
