This reverts commit ea55438a53.
Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview
Original change's description:
> [sparkplug] Support bytecode / baseline code flushing with sparkplug
>
> Currently with sparkplug we don't flush bytecode / baseline code of
> functions that were tiered up to sparkplug. This CL adds the support to
> flush baseline code / bytecode of functions that have baseline code too.
> This CL:
> 1. Updates the BodyDescriptor of JSFunction to treat the Code field of
> JSFunction as a custom weak pointer where the code is treated as weak if
> the bytecode corresponding to this function is old.
> 2. Updates GC to handle the functions that had a weak code object during
> the atomic phase of GC.
> 3. Updates the check for old bytecode to also consider when there is
> baseline code on the function.
>
> This CL doesn't change any heuristics for flushing. The baseline code
> will be flushed at the same time as bytecode.
>
> Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
> Bug: v8:11947
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75674}
Bug: v8:11947
Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75679}
A single ClusterFuzz report flushed out two minor issues in the
bit fiddling routines.
Bug: chromium:1227752,v8:11515
Change-Id: I16ab914b7c3859f55aa141ced371dd80171d0cb5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017809
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75678}
Add discarded of memory on memory reducing garbage collections. In
addition, add tracking of discarded memory and properly adjust the
resident memory of heap dumps.
- Memory is discarded during sweeping and the counter is persistent
across garbage collection cycles.
- Subsequent sweep calls are not supposed to touch the memory anymore.
- As a simplification, discarded memory is tracked on page granularity
and assumed to be fully paged in as soon as a page's free list entries
are reused for allocation.
Change-Id: Icfd58f49f3400c4df0d482e20326a0c43c1ca9f5
Bug: chromium:1056170
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015563
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75677}
The recently added experimental support for non-nullable locals
(https://chromium-review.googlesource.com/c/v8/v8/+/3010283) made
DecodeLocalGet slightly bigger, which caused Clang not to inline
it any more, which has a measurable performance impact because this
is one of the hottest decoding functions. Forcibly inlining it
fixes the regression.
Bug: chromium:1227332
Change-Id: Ifb85f7f5a43ad1c0376bbf37e4af84fb4903371f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018206
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75676}
Currently with sparkplug we don't flush bytecode / baseline code of
functions that were tiered up to sparkplug. This CL adds the support to
flush baseline code / bytecode of functions that have baseline code too.
This CL:
1. Updates the BodyDescriptor of JSFunction to treat the Code field of
JSFunction as a custom weak pointer where the code is treated as weak if
the bytecode corresponding to this function is old.
2. Updates GC to handle the functions that had a weak code object during
the atomic phase of GC.
3. Updates the check for old bytecode to also consider when there is
baseline code on the function.
This CL doesn't change any heuristics for flushing. The baseline code
will be flushed at the same time as bytecode.
Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a
Bug: v8:11947
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75674}
Instantiation was inside a DCHECK and therefore did not happen in
non-debug modes. Turn the DCHECK into a CHECK.
R=clemensb@chromium.org
Bug: chromium:1227685
Change-Id: I13240109326a2c94576f6651963543187d96ad3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017806
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75673}
This CL makes `AllocateUninitializedJSArrayWithElements` always perform
inline allocation, regardless of the `v8_allocation_folding` flag.
Since there are other hand crafted folded-allocations in v8 (e.g. json
parser), it is hard to catch and fix them all, including this one. Also
this function will trigger an IR compilation error at the moment with
`V8_ALLOCATION_FOLDING_BOOL = true`.
So it's better to revert it instead of fixing the compilation error
and make the code more complex.
PS: The `inline_allocation` check was introduced by https://chromium-review.googlesource.com/c/v8/v8/+/2946667.
Change-Id: Ia88dcc23bec47a7aefb3315dd73f6d80452053b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017695
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Cr-Commit-Position: refs/heads/master@{#75672}
Port [wasm][liftoff][ia32][x64] Detect SIMD NaNs for fuzzing
Change-Id: I166ee58ad1fe682847ee252db134ab615056b416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020545
Reviewed-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/master@{#75671}
Enforcing this invariant allows for assuming that free memory is left
untouched.
Bug: chromium:1056170
Change-Id: Ia225a31bbe6d394b8310ce512ed4f76f78e5c177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017808
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75669}
Rolling v8/build: 9d1af1f..1ed240a
Rolling v8/third_party/aemu-linux-x64: czR22wy3jcAfrw7l4ljto3qX6BpD2DSahnluWvqUockC..QunhZeUueNJF63FP9uXIb-TVJNazpdKD5TQAi_D7ZLEC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/e397699..71adf4f
Rolling v8/third_party/fuchsia-sdk: 1ea7a15..1889684
Rolling v8/third_party/logdog/logdog: 9a84af8..794d09a
Rolling v8/tools/clang: d0c5792..3fa8198
Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86
Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86
Rolling v8/tools/luci-go: git_revision:6808332cfd84a07aeefa906674273fc762510c8c..git_revision:2f836b4882d2fa8c7a44c8ac8881c3a17fad6a86
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I714e9cde0aab93bd7d762a9e56cefcd1320e9711
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017145
Reviewed-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@{#75665}
This CL implements the resolution of function overloads based on
run-time checks of the type of arguments passed to the JS function.
For the moment, the only supported overload resolution is between
JSArrays and TypedArrays.
Bug: v8:11739
Change-Id: Iabb79149f021037470a3adf071d1cccb6f00acd1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2987599
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75664}
The Schönhage-Strassen method for *very* large inputs.
This is a reland of 347ba35716,
with added zero-initialization to pacify MSan (spurious report).
Originally:
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3000742
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75659}
Bug: v8:11515
Change-Id: Ieac6e174bde6eb09af0a9a9a49969feabca79e81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3018081
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75663}
I noticed a case where Torque can generate an invalid .inc file, and I
think that it's worth adding a check that can emit an error during
run_torque rather than letting the developer hit a C++ compilation
failure later.
Example error message, if you add @export to StrongDescriptorArray:
Torque Error: Exported class StrongDescriptorArray cannot be in the same
file as its parent extern class DescriptorArray
Bug: v8:7793
Change-Id: Ia69124a4177bd7a53f95442249fae88cb16e354a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015655
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75662}
Reset the instance before the test run, to ensure it runs with the
same initial state as the reference run.
R=clemensb@chromium.org
Bug: chromium:1227591
Change-Id: Ie78b4b84e3df37ab8955c240f1d41e2f5e89a5de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015572
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75658}
We cannot emit the constant pool within the safepoint table data. It
seems like we also don't do that, but the forgotten
{BlockConstPoolScope} triggered a DCHECK.
R=leszeks@chromium.org
Bug: chromium:1227351, chromium:1217074
Change-Id: I187004c83e05002c651a15643bddea5b02cb00c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015559
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75657}
To get there, also:
- Refactor AllocationSite serialization as necessary.
- Make some accessors on AllocationSite atomic.
- Add JSObjectRef::raw_properties_or_hash().
- Eliminate use of IsFastLiteral in JSCallReducer. It isn't really
needed there and we want to have only a single piece of code
traversing boilerplates. (We still have a separate traversal in the
serializer but that will be removed soon.)
- Merge IsFastLiteral checks into JSCreateLowering's
TryAllocateFastLiteral.
Note: TryAllocateFastLiteral doesn't explicitly look at the
boilerplate's elements kind beyond bailing out for
DICTIONARY_ELEMENTS in the beginning. After that it looks only at
the backing store instance type. There is no room for confusion
because, while elements kind transitions can generally happen
concurrently to TryAllocateFastLiteral, boilerplates can never
transition to DICTIONARY_ELEMENTS (added a CHECK for that).
- Slightly adapt CompilationDependencies and remove obsolete comments.
- Fix JSHeapBroker::ClearReconstructibleData (clearing of Refs in
stress mode) to exclude JSObjectRefs with extra data.
Bug: v8:7790
Change-Id: Iee1232d01e04bcd00db04d48f6e82064fce6ff62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008894
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75656}
Wasm has the attribute sourceLineToBytecodePosition and adds the source
lines via setSourceLineToBytecodePosition in which they are 0-based.
Non-Wasm doesn't have that attribute and uses insertSourcePositions
which is 1-based. In non-wasm we are being off by one.
As a note, the sourcePositionsInRange call in insertSourcePositions
doesn't return a list for Wasm since they rely on
setSourceLineToBytecodePosition and therefore do not have that
off-by-one error.
Drive-by: Several elements have the same source position so update
addHtmlElementToSourcePosition to handle more than one element.
Drive-by: Renames due to having the same name but different
capitalization, which was confusing.
Bug: v8:7327
Change-Id: Ie8a066ca629054a5f5a754deec0ed1917bed2b33
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008634
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75655}
This is a bit odd, since `V8DebuggerScript::setBreakpoint()` is declared
as pure virtual in the header file, and the actual implementation is
inside the source file, in `ActualScript::setBreakpoint()`. So this is
dead code that was somehow not detected as such by the C++ compiler.
Bug: chromium:700516, chromium:1162229
Change-Id: Ifc7aa6926c21edbb0b6a5176a35711186c4958cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017801
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75654}
GCInfoIndex cannot be used for a canonicalization of type names.
Example by omerkatz:
struct A : public GCed<A>, public NameProvider {
override const char* GetHumanReadableName() { return "A"; }
};
struct B : public A {
override const char* GetHumanReadableName() { return "B"; }
};
A and B will have the same GCInfoIndex but different type names.
Bug: chromium:1056170
Change-Id: I35b76a0d80498b8c39e3788f6c2556cdb29f3a7b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013311
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75649}
Now that TurboProp doesn't have an earlier interupt budget, we
should no longer be scaling the number of ticks required to
OSR to TurboProp.
BUG=v8:9684
Change-Id: Ie4d41e75df697e36e7fbc3f7bc8a8d0f24f6743a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3014462
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75647}
This is a reland of 819c3ae2f8
Original change's description:
> Reland "Reland "Improve error messages for property access on null/undefined""
>
> This is a reland of 8b18c5e6a5
>
> Original change's description:
> > Reland "Improve error messages for property access on null/undefined"
> >
> > This is a reland of 24c626c1f7
> >
> > Original change's description:
> > > Improve error messages for property access on null/undefined
> > >
> > > Only print the property name when accessing null/undefined if we can
> > > convert it to a string without causing side effects.
> > > If we can't, omit the property name in the error message.
> > > This should avoid confusion when the key is an object with toString().
> > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
> > > Object]' anymore, which was misleading since the property accessed would
> > > be 'a', but we can't evaluate the key without side effects.
> > >
> > > Bug: v8:11365
> > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
> > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#75250}
> >
> > Bug: v8:11365
> > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Patrick Thier <pthier@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75571}
>
> Bug: v8:11365
> Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
> Auto-Submit: Patrick Thier <pthier@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75604}
Bug: v8:11365
Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75645}
Most register and immediate inputs are 5 bits long and 0x1f is used
as mask. Some immediates are byte sized in which case 0xff had to
be used.
Change-Id: Id7568732db9141743c839a2d1d21a27983547aba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009811
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75644}
This is a reland of 8d3c809349 to make
UBsan happy: memcopy (and therefore MemCopy) seems to expect a non-null
src even when the given size is 0, so avoid calling it in that case.
Original change's description:
> [factory] Make NewByteArray return canonical empty byte array
>
> ... for length = 0, analogously to what e.g. NewFixedArray does.
>
> Simplify some call sites that had special handling for this case
> (there are others that didn't).
>
> Change-Id: Ib3de5506300e967aca072fad53df7ab04ef68839
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009225
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75629}
Change-Id: Ib8dc471d63a4b11b846e9d436555a3615902b66f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3014456
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75642}
The stack overflow used to occur when too many bound functions
are nested. The CL also adds a regression test.
Bug: chromium:1226264
Change-Id: I34329d8392d2385207dbd9a8d3188ad4f7cb3c2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011161
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75640}
Setting promise hooks after running some promise-related code has hard
to control side-effects that make correctness fuzzing difficult.
Certain Promise functions are optimized and avoid creating intermediate
Promises. Dynamically enabled Promise hooks combined with --force-slow-path,
which would cause us to always create those intermediate Promises, will
get us very differet callbacks if the hooks are enabled half-way.
The exepected usage pattern is to only use setHooks if there are no
pending promises, something that cannot be guaranteed for fuzzing.
Bug: chromium:1202465
Change-Id: Ifa96f2db9c441b6f5da696b88a1c087160ec8eeb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013355
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75637}
The JSCallWithArraylike can be replaced with a JSCall if its probable arguments list is empty literal array. This replacement will introduce a deoptimization check to make sure the length of arguments list is 0 at runtime.
This CL change this optimization to a diamond speculation which may help avoid deoptimization once and keep the fast path. This change may benefit a following usecase,
function calcMax(testArray) {
Array.max = function(array) {
return Math.max.apply(Math, array);
};
var result = [];
for (var i = 0; i < testArray.length - 3; i++) {
var positiveNumbers = [];
for (var j = 0; j < 3; j++) {
if (testArray[i + j] > 0) {
positiveNumbers.push(testArray[i + j]);
}
}
result.push(Array.max(positiveNumbers));
}
return result;
}
testArray = [-1, 2, 3, -4, -5, -6, -7, -8, -9, 10];
for (var i = 0; i < 1000000; i++) {
calcMax(testArray);
}
Bug: v8:9974
Change-Id: I595627e2fd937527350c8f8652d701c791b41dd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967757
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75636}
If we underestimate the size of the assembler buffer when compiling
directly on the GC heap, we fallback to off-heap compilation and
the Code object is incomplete in the memory.
We know a Code object is incomplete when its relocation_info is
undefined.
Bug: v8:11872
Change-Id: I282fd442e0bf227d9d2cca5a47b3139030f5d64e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013937
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75634}
Add an option to use Liftoff instead of the interpreter as the reference
tier for fuzzing. The tier to use is chosen based on the input data
before generating the module. This way, the module can use features
depending on what is available in the reference tier, and we still get a
chance to find correctness issues that would only be detected by the
interpreter.
R=clemensb@chromium.org
Bug: v8:11856
Change-Id: I2e9878345355a37caec5fdb338dda42a84e8e63a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008645
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75633}
Trap handling is not implemented yet for memory64. Make sure that no
code tries to use it, by setting {NativeModule::bounds_checks_}
accordingly.
This requires some changes to tests to make sure that the
{WasmModule::is_memory64} field is set before creating the corresponding
{NativeModule}.
R=ahaas@chromium.org
Bug: v8:10949
Change-Id: I11d9544b603fc471e3368bb4e7487da4711293a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011167
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75632}
This reverts commit 8d3c809349.
Reason for revert: Fails on UBSan (nullptr on memcpy): https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/17246/overview
Original change's description:
> [factory] Make NewByteArray return canonical empty byte array
>
> ... for length = 0, analogously to what e.g. NewFixedArray does.
>
> Simplify some call sites that had special handling for this case
> (there are others that didn't).
>
> Change-Id: Ib3de5506300e967aca072fad53df7ab04ef68839
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009225
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75629}
Change-Id: I0cb1667b98a2f9285706c2623671d532419d1395
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013358
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75631}
