Reason for revert:
The decision for the specification was to not have this syntax, and instead the syntax before this patch.
Original issue's description:
> [regexp] Support unicode capture names in non-unicode patterns
>
> This ensures that capture names containing surrogate pairs are parsed
> correctly even in non-unicode RegExp patterns by introducing a new
> scanning mode which unconditionally combines surrogate pairs.
>
> BUG=v8:5437,v8:6192
>
> Review-Url: https://codereview.chromium.org/2791163003
> Cr-Commit-Position: refs/heads/master@{#44466}
> Committed: a8651c5671R=yangguo@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2859933003
Cr-Commit-Position: refs/heads/master@{#45088}
Make sure that the input to ChangeFloat64ToTagged is definitely of type
Number, because the operator cannot deal with non-Number inputs.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2858153003
Cr-Commit-Position: refs/heads/master@{#45087}
The functions are validated later during graph generation.
This change uncovered a memory leak, which is now also fixed.
R=ahaas@chromium.org
Change-Id: I0150817da131c5c611fe21b156da9d9d00d4827d
Reviewed-on: https://chromium-review.googlesource.com/490088
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45086}
Now non-atomic color transition operations return a boolean indicating
whether the transition succeeded or not.
This allows to replace color check and transition operations with a
single transition operation. For example:
if (IsWhite(object)) {
WhiteToBlack(object);
Foo();
}
becomes
if (WhiteToBlack(object)) {
Foo();
}
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2857713002
Cr-Commit-Position: refs/heads/master@{#45085}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
1. Generalize context specialization such that the provided context
can be any outer context of the function, not necessarily the
immediate outer context.
2. Based on this: if function specialization is disabled, then
specialize for the module context if there is one.
3. Extend typed lowering of module loads and stores such that if
the operand is a Module constant, we constant-fold the cell load.
That is, a JSLoadModule with a Module HeapConstant input becomes
a LoadField with a Cell HeapConstant input, and similarly for
JSStoreModule.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2841613002
Cr-Commit-Position: refs/heads/master@{#45083}
Remove the --zap_code_space flag and always patch deopted code to hard fail
if called.
Also, as a drive-by add deopt code patching for Arm64.
BUG=v8:6246
Change-Id: Ibf1bc53692dbbe618132100a66c56a88c97fd62b
Reviewed-on: https://chromium-review.googlesource.com/496127
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45082}
It's not clear what this logic is there for; ICU seems to already
preserve the locale in the way that the comment mentions. There
appear to be tests in test/intl/general/mapped-locale.js which
remain passing.
Bug: v8:5751
Change-Id: Ib9c64f00b982711ae0eab078252a88f44b81b894
Reviewed-on: https://chromium-review.googlesource.com/485780
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45080}
Note that this just switches from the AST-based validator to a dedicated
parser for asm.js modules. The validation of asm.js modules in general
still is predicated by the "--validate-asm" flag, and not enabled by
default yet.
R=clemensh@chromium.org,marja@chromium.org
BUG=v8:6127
Change-Id: Ibd920b03e20ec3c70ee51b79c6c5a2043964fe4f
Reviewed-on: https://chromium-review.googlesource.com/496146
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45078}
AllocateGuarded previously fell back on Allocate and then called Guard
to set the protection to PROT_NONE. Linux commits RW memory, but the
important thing here is to reserve the address space without committing
it. This change adds a new variant of Allocate that takes explicit
permission bits so that AllocateGuarded allocates non-RW memory from the
beginning.
Bug: v8:6320
Change-Id: I7962acbed09938951bf3bb4af2d1f302adba2547
Reviewed-on: https://chromium-review.googlesource.com/491928
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45075}
In the spirit of the full MC, we evacuate and update pointers in parallel for
the young generation.
The collectors are connected during incremental marking when mark bits are
transferred from the young generation bitmap to the old generation bitmap.
The evacuation phase cannot (yet) move pages and relies completely on copying
objects.
BUG=chromium:651354
Review-Url: https://codereview.chromium.org/2796233003
Cr-Commit-Position: refs/heads/master@{#45074}
-fsanitize-coverage={edge,bb,func} are deprecated.
-fsanitize-coverage={edge,bb,func},trace-pc-guard should be used instead (edge is default).
BUG=chromium:651540
Review-Url: https://codereview.chromium.org/2860653002
Cr-Commit-Position: refs/heads/master@{#45072}
When deleting the most recently added fast property from an object
by undoing its last map transition, we must clear any recorded slots.
This can only be done in C++, so this functionality must move out
of the stub.
Also update a CHECK in the JSObject verifier to allow backing stores
sticking around after such property deletions.
BUG=chromium:716912,chromium:714981
Review-Url: https://codereview.chromium.org/2854373002
Cr-Commit-Position: refs/heads/master@{#45069}
If a negative value is passed as end position it may get past the end
without triggering any DCHECK due to int to size_t cast.
BUG=v8:6093
Change-Id: I0c6be0e8442049cc4b7fc87593ad018bce4b677e
Reviewed-on: https://chromium-review.googlesource.com/494108
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45068}
by pulling parameterizable things out of the case-blocks.
No change in functionality.
BUG=chromium:714894
Review-Url: https://codereview.chromium.org/2854273004
Cr-Commit-Position: refs/heads/master@{#45066}
More care must be taken to remain on the fast path in the face of
@@species constructors.
BUG=chromium:716044
Review-Url: https://codereview.chromium.org/2846963003
Cr-Commit-Position: refs/heads/master@{#45065}
Blink uses Isolate::GetEnteredContext() to implement HTML's "entry
context" concept, and thus depends on it not being changed except
explicitly (by Blink.) To support this, stop entering contexts
implicitly in all external API entry points; rather just set the
context as current. The only thing that changes the entered context
is now Context::Enter()/Context::Exit() (and Context::Scope.)
BUG=v8:6307
Review-Url: https://codereview.chromium.org/2862483003
Cr-Commit-Position: refs/heads/master@{#45064}
There is no point in doing black allocation here as we then have to
iterate the objects for various reasons. The marker does the same work
but can be moved outside of the atomic pause.
BUG=chromium:581412
Review-Url: https://codereview.chromium.org/2862563002
Cr-Commit-Position: refs/heads/master@{#45063}
During computation of the side table, ignore stack effects of
instructions following any unconditional jump in the same block
(|unreachable|, |br|, |br_table| or |return| jump out of the block).
Without this fix, the current stack height might underflow, or we compute an
unnecessarily large max_stack_height_. Note that those instruction will
never get executed anyway.
Hence, we don't need to store any side table information for such
unreachable code.
R=rossberg@chromium.org
BUG=chromium:716936, chromium:715990
Change-Id: I282f7f18ba1b972a112210e692f6cd05cf32308c
Reviewed-on: https://chromium-review.googlesource.com/493266
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45059}
This fixes cases where the omission of return type annotation of calls
to stdlib function was rejected, because a surrounding {fround} call
used to be misinterpreted as an annotation instead of a rounding.
R=clemensh@chromium.org
TEST=mjsunit/asm/call-stdlib
BUG=v8:6127
Change-Id: Idec0ef1740ebf8eda969ff05dd1c90252de87a6b
Reviewed-on: https://chromium-review.googlesource.com/493349
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45057}
We can use FinalizeIncrementalMarking instead since the only caller of
TryFinalizeIdleIncrementalMarking is IdleNotification, for which staying
within idle deadline is not critical.
This also fixes a bug caused by inconsistent code duplication in
finalization condition in the two functions.
BUG=v8:6325,chromium:715457
Review-Url: https://codereview.chromium.org/2851743002
Cr-Commit-Position: refs/heads/master@{#45054}
When we don't know the call count for a given call site (i.e. for
inlined accessors), we put 0 as call frequency so far. But as of
https://codereview.chromium.org/2859433002, this would completely
disable the inlining of those calls, since 0 is interpreted as never
called, which is not what we want. So instead of defaulting to 0,
add a dedicated sentinel, whose value is NaN, which makes the call
site eligible for inlining, but not high priority (as it was before
the CL mentioned above).
BUG=v8:4493,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2856103002
Cr-Commit-Position: refs/heads/master@{#45053}
This reverts commit 7683df248a.
Reason for revert: doesn't help with gcc, so removing
Original change's description:
> Disable -Werror=attributes on gcc
>
> The warning triggers even if the attributes don't change - it's enough
> to declare them multiple times. Given that the other compilers don't
> complain, just disable the warning on gcc for now.
>
> R=jkummerow@chromium.org,mtrofin@chromium.org
> BUG=v8:6339
> NOTRY=true
>
> Change-Id: Ie0fcc4feeb8568d4ab74ac65f6887523f3cdcbf9
> Reviewed-on: https://chromium-review.googlesource.com/494106
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45045}
TBR=jkummerow@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,gsathya@chromium.org,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6339
Change-Id: I581e4f0499ae0d7e3bc791fd6fa9988aabe64c5e
Reviewed-on: https://chromium-review.googlesource.com/494469
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45052}
We only need to materialize the existing output register for a given
register transfer if it is in a different equivalence set, otherwise we
already have the value we want in the output register.
BUG=v8:4280
Change-Id: Ic4966590ac10445180aff353940d2c93e6a818aa
Reviewed-on: https://chromium-review.googlesource.com/493168
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45051}
Test typedarray-arg-set-values-same-buffer-other-type fails on
big-endian platforms due to the issue in the test itself. The issue has
been reported to test262 maintainers, until resolved the test is skipped.
TEST=test262/built-ins/TypedArray/prototype/set/typedarray-arg-set-values-same-buffer-other-type
BUG=
Review-Url: https://codereview.chromium.org/2834093002
Cr-Commit-Position: refs/heads/master@{#45048}
The --wasm-interpret-all flag is mainly used for debugging. Combining it
with lazy compilation is unreasonable and would create a lot of special
cases in both code paths. Hence this CL disallows the combination of
these two flags by adding a negative flag implication.
R=rossberg@chromium.org
BUG=chromium:715216
Change-Id: I777e21d7e64f567e2728498dbb6f5b0709cd28f1
Reviewed-on: https://chromium-review.googlesource.com/494486
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45047}
Adds tests for Heap::IsUnmodifiedHeapObject that is used during
scavenge.
Bug:
Change-Id: Ide549a6616101cbd6ed17372ed1ed168c7a76fbd
Reviewed-on: https://chromium-review.googlesource.com/484539
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45046}
The warning triggers even if the attributes don't change - it's enough
to declare them multiple times. Given that the other compilers don't
complain, just disable the warning on gcc for now.
R=jkummerow@chromium.org,mtrofin@chromium.org
BUG=v8:6339
NOTRY=true
Change-Id: Ie0fcc4feeb8568d4ab74ac65f6887523f3cdcbf9
Reviewed-on: https://chromium-review.googlesource.com/494106
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45045}
I'd like to change the parser to not create those AST nodes in
the first place. To get there, I'm skipping visiting of those nodes
in the existing visitors.
With this change, there is only one visitor in asm-to-wasm left that
actually visits those nodes, and seemingly depends on it.
R=adamk@chromium.org
BUG=v8:6312
Change-Id: I0837fdd97cf4c1baefa2d7fd76eddd90ad00b1df
Reviewed-on: https://chromium-review.googlesource.com/493167
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45044}
This patch adds a concurrent marking deque that exposes the same interface
for the main thread as the existing marking deque.
The matching interface makes the concurrent marking deque a drop-in
replacement for the sequential marking deque without any change in
mark-compactor and incremental marker.
BUG=chromium:694255
Review-Url: https://codereview.chromium.org/2810893002
Cr-Commit-Position: refs/heads/master@{#45042}
Executing the |end| opcode of a loop assumed that the stack height was
being reset to the height at start of the loop. Hence we were ignoring
the arity of the loop.
During computation of the side table, the arity of the label associated
with the loop was explicitly set to 0, such that a |br| instruction to
that label would not transfer any values.
It turns out though that we need to remember the arity in order to
precompute the correct stack height when executing the |end| opcode of
a loop.
Also, add a regression test.
R=rossberg@chromium.org
BUG=chromium:716936
Change-Id: Ib3a559998f1ce5f8fcd7b94af1426637b3e48f86
Reviewed-on: https://chromium-review.googlesource.com/493286
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45041}
