Fix invalid usage of layout_descriptor() function on 32-bit arch's,
which doesn't perform necessary checks. Test failure is observed only on
mips32 big-endian, and on mips32 little-endian as an alignment issue,
but the problem appears to be generic for all 32-bit arch's.
TEST=test/mjsunit/es6/classes-subclass-builtins.js
BUG=
Review URL: https://codereview.chromium.org/1522203004
Cr-Commit-Position: refs/heads/master@{#32887}
The TypeOfStub didn't test the undetectable bit properly if the instance
was also callable, and therefore returned "object" for document.all
(which is both undetectable and callable).
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=yangguo@chromium.org
BUG=chromium:567998
LOG=n
Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc
Cr-Commit-Position: refs/heads/master@{#32852}
Review URL: https://codereview.chromium.org/1527863003
Cr-Commit-Position: refs/heads/master@{#32883}
If JSCreate (which corresponds to %NewObject) would ever trigger a lazy
deopt, we would deopt after the constructor call, skipping all the
initialization and what else in the constructor function, which is
wrong. Instead we can use the eager bailout point right before the
constructor function, because allocation is not observable and so we can
safely repeat the %NewObject in case of lazy bailout.
R=yangguo@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1530583004
Cr-Commit-Position: refs/heads/master@{#32880}
With the handle canonicalization we can now easily cache heap constant
nodes based on the location of the HeapObject handle location.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1523323005
Cr-Commit-Position: refs/heads/master@{#32876}
The regression the bug tracks (see the bug link) appears to
be due to identical gap moves in the predecessors of a block
not being moved to the common successor. This CR fixes one
reason that is happening.
BUG=chromium:549262
LOG=n
Review URL: https://codereview.chromium.org/1523393003
Cr-Commit-Position: refs/heads/master@{#32874}
Rolling v8/third_party/icu to 8d342a405be5ae8aacb1e16f0bc31c3a4fbf26a2
Rolling v8/tools/clang to 6261565695263bd878edd055e81ecc5e989711d6
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1529973004
Cr-Commit-Position: refs/heads/master@{#32873}
The proxy may be on its own target's or handler's prototype chain, leading
to infinite recursion either when looking up the trap, or when calling
through to the target.
We can't eagerly prevent this from happening (e.g. at "foo.__proto__ = bar"
calling time) because the presence of traps can change at any time.
BUG=v8:1543,chromium:569882
LOG=n
Review URL: https://codereview.chromium.org/1526953002
Cr-Commit-Position: refs/heads/master@{#32872}
This fixes a path in the compilation pipeline that side-stepped the
interpreter when a function literal was eagerly compiled. This caused
the interpreter to miss some test coverage.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1528853002
Cr-Commit-Position: refs/heads/master@{#32867}
The CL 32796(https://codereview.chromium.org/1512023002) adds many Float32 comparision test data which including the NaN comparision.
As there's no Specification for the return value of NaN comparision, Current x87 will check the Float comparision instruction's first
operand, if it's NaN, return the second operand. Otherwise, return itself.
But this conflicts with the Gcc compiler's implementation and cause the RunFloat32MinP and RunFloat32MaxP tests failed.
For (a < b) comparision, The Gcc compiler will treat the NaN comparision's result same as a GT b and return b.
The minss sse instruction in IA32 has the similar behavior.
So this CL will make the implementation of NaN comparision's return value in kX87Float32Min and kX87Float32Max same as Gcc and IA32.
BUG=
Review URL: https://codereview.chromium.org/1522333002
Cr-Commit-Position: refs/heads/master@{#32866}
The third argument optionally specifies the frame from which to step.
This feature is not used and not well tested.
R=jkummerow@chromium.org
BUG=chromium:569835
LOG=N
Review URL: https://codereview.chromium.org/1525993002
Cr-Commit-Position: refs/heads/master@{#32865}
This fixes runtime calls emitted by the RawMachineAssembler to use the
correct CEntryStub depending on the return count of runtime functions.
Note that this only affects WIN64 and PPC, where the ABI is different.
R=mythria@chromium.org
Review URL: https://codereview.chromium.org/1528643004
Cr-Commit-Position: refs/heads/master@{#32864}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32857}
We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.
This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.
R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N
Review URL: https://codereview.chromium.org/1527593002
Cr-Commit-Position: refs/heads/master@{#32856}
The TypeOfStub didn't test the undetectable bit properly if the instance
was also callable, and therefore returned "object" for document.all
(which is both undetectable and callable).
R=yangguo@chromium.org
BUG=chromium:567998
LOG=n
Review URL: https://codereview.chromium.org/1527863003
Cr-Commit-Position: refs/heads/master@{#32852}
Turning it off broke both the trace viewer and using the devtools
to connect to an earlier version of Chrome running on another device.
BUG=chromium:552100, chromium:569417, chromium:569647
TBR=rossberg@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1521993004 .
Cr-Commit-Position: refs/heads/master@{#32850}
Rolling v8/build/gyp to b85ad3e578da830377dbc1843aa4fbc5af17a192
Rolling v8/tools/clang to f8fd8b699f6c474577b455e55b22df23ceaa2da8
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1527613005
Cr-Commit-Position: refs/heads/master@{#32849}
This unifies the decision whether to use Ignition or FullCodeGenerator
to generate baseline code into a single place. This allows for small
function literals that are compiled eagerly to go through Ignition.
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1525663002
Cr-Commit-Position: refs/heads/master@{#32848}
This removes the ability to generate stub code via the full-fledged
compiler pipeline that parses and analyzes JavaScript source code.
Generation of stub code has been moved to a lower-level entry point.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1520373002
Cr-Commit-Position: refs/heads/master@{#32847}
Reason for revert:
[Sheriff] Layout test changes.
Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1526553003
Cr-Commit-Position: refs/heads/master@{#32845}
- proxies-with-unscopables needed updating of trap names
- proxies-symbols doesn't make sense any more: it tested symbol fitering/
blacklisting, but Proxies interact with Symbols just fine according to
the current spec.
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1529473002
Cr-Commit-Position: refs/heads/master@{#32844}
This CL tries to correctly support the following:
- stringifying a proxy,
- stringifying with a proxy as replacer (callable or arraylike),
- stringifying with a replacer that returns a proxy,
- parsing with a callable proxy as reviver,
- parsing with a reviver that inserts proxies into the object,
- and whatever else you can imagine.
This also fixes some bugs observable without proxies.
BUG=v8:3139,v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1515133002
Cr-Commit-Position: refs/heads/master@{#32843}
The test Run_Wasm_StoreMem_offset_oob contained an I64STORE instruction,
which is not yet implemented on 32 bit platforms. I turned off those
parts of the test on 32 bit platforms which contain I64 instructions.
R=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1526573002
Cr-Commit-Position: refs/heads/master@{#32842}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32841}
