- 05 Nov, 2015 3 commits
-
-
littledan authored
This patch moves ES2015 ToLength semantics on array operations, etc to from staging to shipping. R=adamk BUG=v8:3087 LOG=Y Review URL: https://codereview.chromium.org/1433473003 Cr-Commit-Position: refs/heads/master@{#31810}
-
littledan authored
The maximum indexed element size is maxUint32-1, not maxUint32, because the maximum length of elements is maxUint32. This patch tweaks the limit to switch to named properties as appropriate. BUG=v8:4516 LOG=Y R=adamk Review URL: https://codereview.chromium.org/1431503002 Cr-Commit-Position: refs/heads/master@{#31809}
-
chunyang.dai authored
The CL https://codereview.chromium.org/1409013004 added / changed some test cases. Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function, those inlined functions has different behavior comparing with GCC ia32 build and x87 build. The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value. The V8 turbofan JITTed has exactly same result in both X87 and IA32 port. So we add the following sentence to do type case to keep the same precision. float expect = *i * *j; // *i + *j, etc. For test case "RunFloat64MulAndFloat64Add1 / RunFloat64MulAndFloat64Add2 / RunFloat64MulAndFloat64Sub1 / RunFloat64MulAndFloat64Sub2", the expected result calcaulated by GCC has difference precsion when comparing with V8 turbofan result for X87 platform. (Turbofan X87 result is the same as IA32 GCC and IA32 Turbofan). So we have to disable those four cases for X87 port. BUG= Review URL: https://codereview.chromium.org/1430943002 Cr-Commit-Position: refs/heads/master@{#31808}
-
- 04 Nov, 2015 37 commits
-
-
paul.lind authored
From 41f3e782. BUG= Review URL: https://codereview.chromium.org/1431843002 Cr-Commit-Position: refs/heads/master@{#31807}
-
dusan.m.milosavljevic authored
TEST=cctest/test-run-machops/Float(64|32)MaxP, Float(64|32)MinP, unittests/InstructionSelectorTest.Float64Min|Max BUG=v8:4206 LOG=N Review URL: https://codereview.chromium.org/1419753008 Cr-Commit-Position: refs/heads/master@{#31806}
-
yangguo authored
R=bmeurer@chromium.org Committed: https://crrev.com/5a1e42c039ac3379ebe1e7e34fb8163e1ec1493e Cr-Commit-Position: refs/heads/master@{#31791} Review URL: https://codereview.chromium.org/1428203003 Cr-Commit-Position: refs/heads/master@{#31805}
-
yangguo authored
R=littledan@chromium.org BUG=v8:3715, v8:4528 LOG=Y Committed: https://crrev.com/60e8877e161fe6175e19fafce2d6ed1c3999cdb1 Cr-Commit-Position: refs/heads/master@{#31753} Committed: https://crrev.com/b5c80a31ad266eb38a0cf2ff756be59c66d34aa5 Cr-Commit-Position: refs/heads/master@{#31773} Committed: https://crrev.com/85494e90bb63a3a9e19a1bf862cb6bfcb0162ee9 Cr-Commit-Position: refs/heads/master@{#31782} Review URL: https://codereview.chromium.org/1419823010 Cr-Commit-Position: refs/heads/master@{#31804}
-
rmcilroy authored
Avoid double incrementing the variable in the U16() macro. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1431803004 Cr-Commit-Position: refs/heads/master@{#31803}
-
caitpotter88 authored
Emit an early error when BindingPatterns are used in a VariableDeclaration or LexicalBinding without an Initializer. BUG=v8:4532 LOG=N R=adamk@chromium.org, rossberg@chromium.org, wingo@igalia.com Review URL: https://codereview.chromium.org/1416753009 Cr-Commit-Position: refs/heads/master@{#31802}
-
hablich authored
Revert of Implement flag and source getters on RegExp.prototype. (patchset #6 id:110001 of https://codereview.chromium.org/1419823010/ ) Reason for revert: Breaks Chromium tests and blocks the roll: http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/124490 Original issue's description: > Implement flag and source getters on RegExp.prototype. > > R=littledan@chromium.org > BUG=v8:3715, v8:4528 > LOG=Y > > Committed: https://crrev.com/60e8877e161fe6175e19fafce2d6ed1c3999cdb1 > Cr-Commit-Position: refs/heads/master@{#31753} > > Committed: https://crrev.com/b5c80a31ad266eb38a0cf2ff756be59c66d34aa5 > Cr-Commit-Position: refs/heads/master@{#31773} > > Committed: https://crrev.com/85494e90bb63a3a9e19a1bf862cb6bfcb0162ee9 > Cr-Commit-Position: refs/heads/master@{#31782} TBR=littledan@chromium.org,jochen@chromium.org,ulan@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3715, v8:4528 Review URL: https://codereview.chromium.org/1432683002 Cr-Commit-Position: refs/heads/master@{#31801}
-
hablich authored
Revert of Use in-object fields instead of private symbols for regexp slots. (patchset #4 id:60001 of https://codereview.chromium.org/1428203003/ ) Reason for revert: A clean revert of https://codereview.chromium.org/1419823010/ was not possible because of this CL. Thus, I am also reverting this CL. Original issue's description: > Use in-object fields instead of private symbols for regexp slots. > > R=bmeurer@chromium.org > > Committed: https://crrev.com/5a1e42c039ac3379ebe1e7e34fb8163e1ec1493e > Cr-Commit-Position: refs/heads/master@{#31791} TBR=bmeurer@chromium.org,yangguo@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1421593009 Cr-Commit-Position: refs/heads/master@{#31800}
-
mstarzinger authored
This deprecates the ability of the raw machine assembler to utilize the CallFunctionStub in preparation of the stub itself being deprecated. We only used this to test instruction selection of calls to stubs that can deoptimize, the test has been adapted. R=verwaest@chromium.org TEST=unittests/InstructionSelectorTest Review URL: https://codereview.chromium.org/1408193006 Cr-Commit-Position: refs/heads/master@{#31799}
-
adamk authored
Revert of [es6] Implement destructuring binding in try/catch (patchset #3 id:40001 of https://codereview.chromium.org/1417483014/ ) Reason for revert: MSAN errors on arm64: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/5123/ Original issue's description: > [es6] Implement destructuring binding in try/catch > > The approach is to desugar > > try { ... } > catch ({x, y}) { ... } > > into > > try { ... } > catch (.catch) { > let x = .catch.x; > let y = .catch.y; > ... > } > > using the PatternRewriter's normal facilities. This has the side benefit > of throwing the appropriate variable conflict errors for declarations > made inside the catch block. > > No change is made to non-destructured cases, which will hopefully save > us some work if https://github.com/tc39/ecma262/issues/150 is adopted > in the spec. > > There's one big problem with this patch, which is a lack of PreParser > support for the redeclaration errors. But it seems we're already lacking > good PreParser support for such errors, so I'm not sure that should > block this moving forward. > > BUG=v8:811 > LOG=y > > Committed: https://crrev.com/a316db995e6e4253664920652ed4e5a38b2caeba > Cr-Commit-Position: refs/heads/master@{#31797} TBR=rossberg@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:811 Review URL: https://codereview.chromium.org/1408063013 Cr-Commit-Position: refs/heads/master@{#31798}
-
adamk authored
The approach is to desugar try { ... } catch ({x, y}) { ... } into try { ... } catch (.catch) { let x = .catch.x; let y = .catch.y; ... } using the PatternRewriter's normal facilities. This has the side benefit of throwing the appropriate variable conflict errors for declarations made inside the catch block. No change is made to non-destructured cases, which will hopefully save us some work if https://github.com/tc39/ecma262/issues/150 is adopted in the spec. There's one big problem with this patch, which is a lack of PreParser support for the redeclaration errors. But it seems we're already lacking good PreParser support for such errors, so I'm not sure that should block this moving forward. BUG=v8:811 LOG=y Review URL: https://codereview.chromium.org/1417483014 Cr-Commit-Position: refs/heads/master@{#31797}
-
jarin authored
Review URL: https://codereview.chromium.org/1425183003 Cr-Commit-Position: refs/heads/master@{#31796}
-
mbrandy authored
Port 870e908d R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, dstence@us.ibm.com BUG= Review URL: https://codereview.chromium.org/1428133002 Cr-Commit-Position: refs/heads/master@{#31795}
-
bmeurer authored
Use the Call builtin instead, which does the right thing(TM) always, especially since the CallFunctionStub is going away. R=jarin@chromium.org BUG=v8:4413 LOG=n Review URL: https://codereview.chromium.org/1410853007 Cr-Commit-Position: refs/heads/master@{#31794}
-
jarin authored
Review URL: https://codereview.chromium.org/1413153013 Cr-Commit-Position: refs/heads/master@{#31793}
-
mstarzinger authored
This removes several methods from JSFunction that just delegate to SharedFunctionInfo. These methods are especially dangerous when they hide the fact that they potentially affect all function instances deriving from the same underlying SharedFunctionInfo. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1417213005 Cr-Commit-Position: refs/heads/master@{#31792}
-
yangguo authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1428203003 Cr-Commit-Position: refs/heads/master@{#31791}
-
cbruni authored
The current implementation of classes throws the TypeError at the wrong point, after activating a new context when directly calling a class constructor. According to the spec, the TypeError has to be thrown in the caller context. LOG=N BUG=v8:4428 Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90 Cr-Commit-Position: refs/heads/master@{#31786} Review URL: https://codereview.chromium.org/1418623007 Cr-Commit-Position: refs/heads/master@{#31790}
-
bmeurer authored
The callees are expected to properly set the number of actual arguments passed to the callee, which is now represented correctly in the TurboFan graphs by a new Parameter right before the context Parameter. Currently this is only being used for outgoing calls. Note that this requires disabling two of the TF code stub tests, because of the JavaScript graphs are not automagically compatible with abitrary (incoming) code stub interface descriptors. If we want to support JS code stubs at all, then we need to find a sane way to feed in this information. Drive-by-fix: Don't insert a direct call to a classConstructor. R=mstarzinger@chromium.org BUG=v8:4413, v8:4428 LOG=n Review URL: https://codereview.chromium.org/1410633006 Cr-Commit-Position: refs/heads/master@{#31789}
-
cbruni authored
BUG= Review URL: https://codereview.chromium.org/1425403002 Cr-Commit-Position: refs/heads/master@{#31788}
-
cbruni authored
Revert of [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor. (patchset #20 id:370001 of https://codereview.chromium.org/1418623007/ ) Reason for revert: failing build bot Original issue's description: > [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor. > > The current implementation of classes throws the TypeError at the wrong > point, after activating a new context when directly calling a class > constructor. According to the spec, the TypeError has to be thrown > in the caller context. > > LOG=N > BUG=v8:4428 > > Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90 > Cr-Commit-Position: refs/heads/master@{#31786} TBR=bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4428 Review URL: https://codereview.chromium.org/1415783006 Cr-Commit-Position: refs/heads/master@{#31787}
-
cbruni authored
The current implementation of classes throws the TypeError at the wrong point, after activating a new context when directly calling a class constructor. According to the spec, the TypeError has to be thrown in the caller context. LOG=N BUG=v8:4428 Review URL: https://codereview.chromium.org/1418623007 Cr-Commit-Position: refs/heads/master@{#31786}
-
ishell authored
Review URL: https://codereview.chromium.org/1412223018 Cr-Commit-Position: refs/heads/master@{#31785}
-
mstarzinger authored
R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1405963011 Cr-Commit-Position: refs/heads/master@{#31784}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#31783}
-
yangguo authored
R=littledan@chromium.org BUG=v8:3715, v8:4528 LOG=Y Committed: https://crrev.com/60e8877e161fe6175e19fafce2d6ed1c3999cdb1 Cr-Commit-Position: refs/heads/master@{#31753} Committed: https://crrev.com/b5c80a31ad266eb38a0cf2ff756be59c66d34aa5 Cr-Commit-Position: refs/heads/master@{#31773} Review URL: https://codereview.chromium.org/1419823010 Cr-Commit-Position: refs/heads/master@{#31782}
-
bmeurer authored
Call directly into the ArgumentsAdaptorTrampoline when we call a known JSFunction, but that actual argument count doesn't match the expected argument count. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1417213004 Cr-Commit-Position: refs/heads/master@{#31781}
-
yangguo authored
Revert of Implement flag and source getters on RegExp.prototype. (patchset #3 id:50001 of https://codereview.chromium.org/1419823010/ ) Reason for revert: Performance issue. Original issue's description: > Implement flag and source getters on RegExp.prototype. > > R=littledan@chromium.org > BUG=v8:3715, v8:4528 > LOG=Y > > Committed: https://crrev.com/60e8877e161fe6175e19fafce2d6ed1c3999cdb1 > Cr-Commit-Position: refs/heads/master@{#31753} > > Committed: https://crrev.com/b5c80a31ad266eb38a0cf2ff756be59c66d34aa5 > Cr-Commit-Position: refs/heads/master@{#31773} TBR=littledan@chromium.org,jochen@chromium.org,ulan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:3715, v8:4528 Review URL: https://codereview.chromium.org/1409013006 Cr-Commit-Position: refs/heads/master@{#31780}
-
jarin authored
We don't really care about signedness when truncating to Word32. Review URL: https://codereview.chromium.org/1417023005 Cr-Commit-Position: refs/heads/master@{#31779}
-
mstarzinger authored
This makes the description in the README file for our test262 harness independent of the underlying revision. The one canonical place to mention the up-to-date revision is the DEPS file. R=machenbach@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1424043006 Cr-Commit-Position: refs/heads/master@{#31778}
-
machenbach authored
BUG=chromium:535160 LOG=n Review URL: https://codereview.chromium.org/1413033014 Cr-Commit-Position: refs/heads/master@{#31777}
-
mstarzinger authored
This removes special casing for the 'f.arguments' property accessor. Any local 'arguments' variable should not be allowed to influence the value returned by the indirect 'f.arguments' property. That property creates a new object with a separate identity everytime it is read. This is by now consistent with other browsers. R=rossberg@chromium.org TEST=mjsunit/arguments-indirect Review URL: https://codereview.chromium.org/1408983006 Cr-Commit-Position: refs/heads/master@{#31776}
-
jkummerow authored
Review URL: https://codereview.chromium.org/1414403003 Cr-Commit-Position: refs/heads/master@{#31775}
-
rmcilroy authored
Adds support for calling JS runtime functions. Also changes the bytecode array builder to allow calling functions with an invalid argument register if the call takes no arguments. Adds the bytecode CallJSRuntime. BUG=v8:4280 LOG=N Review URL: https://codereview.chromium.org/1410003003 Cr-Commit-Position: refs/heads/master@{#31774}
-
yangguo authored
R=littledan@chromium.org BUG=v8:3715, v8:4528 LOG=Y Committed: https://crrev.com/60e8877e161fe6175e19fafce2d6ed1c3999cdb1 Cr-Commit-Position: refs/heads/master@{#31753} Review URL: https://codereview.chromium.org/1419823010 Cr-Commit-Position: refs/heads/master@{#31773}
-
bmeurer authored
Use the type specified for StoreField and StoreElement to check whether we are storing a TaggedSigned value, and skip the write barrier for the write completely in that case. Also make sure to set that field type appropriately for JSGlobalObjectSpecialization. R=jarin@chromium.org BUG=v8:4470 LOG=n Review URL: https://codereview.chromium.org/1410743009 Cr-Commit-Position: refs/heads/master@{#31772}
-
bmeurer authored
We don't need to distinguish between signed and unsigned integral representations in the big boy type system. It actually even hurts in some cases. The representation is only about the way the values are mapped to bits in memory/registers, but the interpretation of the bits is specified by the semantic dimension. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1416953006 Cr-Commit-Position: refs/heads/master@{#31771}
-