- 30 Jun, 2015 1 commit
-
-
littledan authored
The failure was been triggered by turning on --harmony-arrays, maybe because code size was increased or code was added later in the bootstrap process. Because it doesn't look like a bug in anything guarded by --harmony-arrays directly, I'd suggest shipping the flag and disabling the test on the architectures where it's been observed to fail. It's already disabled on arm64 and this patch disables it on mips64 as well. BUG=v8:4200 LOG=N R=adamk Review URL: https://codereview.chromium.org/1212963004 Cr-Commit-Position: refs/heads/master@{#29361}
-
- 29 Jun, 2015 22 commits
-
-
mbrandy authored
Port 7a63bf77 Original commit message: This makes new.target work in [[Call]] and [[Construct]] of ordinary functions. We achieve this by introducing a new construct stub for functions that uses the new.target variable. The construct stub pushes the original constructor just above the receiver in the construct frame. R=arv@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1213303002 Cr-Commit-Position: refs/heads/master@{#29360}
-
arv authored
BUG=v8:3887 LOG=N R=caitpotter88@gmail.com, adamk@chromium.org Review URL: https://codereview.chromium.org/1215973005 Cr-Commit-Position: refs/heads/master@{#29359}
-
arv authored
This makes new.target work in [[Call]] and [[Construct]] of ordinary functions. We achieve this by introducing a new construct stub for functions that uses the new.target variable. The construct stub pushes the original constructor just above the receiver in the construct frame. BUG=v8:3887 LOG=N R=adamk@chromium.org, dslomov@chromium.org Review URL: https://codereview.chromium.org/1203813002 Cr-Commit-Position: refs/heads/master@{#29358}
-
arv authored
We were calling the setter for Object.prototype.promise if it existed when calling PromiseAll. BUG=v9:4232 LOG=N R=rossberg@chromium.org, adamk@chromium.org Review URL: https://codereview.chromium.org/1219623005 Cr-Commit-Position: refs/heads/master@{#29357}
-
paul.lind authored
zlib is broken for mips after 35eb3a02. We're still working on a fix. Skip test for now, so the bots cycle green. BUG= Review URL: https://codereview.chromium.org/1209253005 Cr-Commit-Position: refs/heads/master@{#29356}
-
oth authored
BUG=chromium:505228 LOG=Y Review URL: https://codereview.chromium.org/1219723002 Cr-Commit-Position: refs/heads/master@{#29355}
-
yangguo authored
Only this way we can precisely determine how to allocate let variables inside the scope. R=rossberg@chromium.org BUG=v8:4255 LOG=N Review URL: https://codereview.chromium.org/1216013002 Cr-Commit-Position: refs/heads/master@{#29354}
-
dusan.milosavljevic authored
Enable skipped test-api/RequestInterruptTestWith* after: https://codereview.chromium.org/1220443002/ TEST= BUG= Review URL: https://codereview.chromium.org/1219683004 Cr-Commit-Position: refs/heads/master@{#29353}
-
mtrofin authored
Separated core greedy allocator concepts, exposing the APIs we would want to continue working with. In particular, this change completely reworks CoalescedLiveRanges to reflect the fact that we expect more than one possible conflict, scrapping the initial design of the structure. Since this is a critical part of the design, this change may be thought of as a full rewrite of the algorithm. Reduced all heuristics to just 2 essential ones: split "somewhere", which we'll still need when all other heuristics fail; and spill. Introduced a simple primitive for splitting - at GapPosition::START. The goal is to use such primitives to quickly and reliably author heuristics. I expected this primitive to "just work" for any arbitrary instruction index within a live range - e.g. its middle. That's not the case, it seems to upset execution in certain scenarios. Restricting to either before/after use positions seems to work. I'm still investigating what the source of failures is in the case of "arbitrary instruction in the range" case. I intended to document the rationale and prove the soundness of always using START for splits, but I will postpone to after this last remaining issue is resolved. Review URL: https://codereview.chromium.org/1205173002 Cr-Commit-Position: refs/heads/master@{#29352}
-
binji authored
This one occurs when Function.prototype.toString is overridden to return a non-string. BUG=chromium:504729 R=mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1214803004 Cr-Commit-Position: refs/heads/master@{#29351}
-
binji authored
Dumb typo introduced in refs/heads/master@{#29306}. I thought I was turning on report_exceptions in Shell::ExecuteString, but instead I turned on print_result (which assumes an interactive debugger and a HandleScope for the utility_context_). BUG=chromium:504727,chromium:504728 R=mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1219563002 Cr-Commit-Position: refs/heads/master@{#29350}
-
machenbach authored
The android_* configs were never real v8 target architectures, only make targets. This doesn't make sense with ninja anymore. BUG=chromium:502176 LOG=n NOTRY=true Review URL: https://codereview.chromium.org/1220743002 Cr-Commit-Position: refs/heads/master@{#29349}
-
ishell authored
BUG=chromium:505367 LOG=N Review URL: https://codereview.chromium.org/1215003002 Cr-Commit-Position: refs/heads/master@{#29348}
-
Djordje.Pesic authored
RegExpCompileEvent acquieres mutex from Log class during MessageBuilder creation. LogRegExpSource, called from RegExpCompileEvent creates another MessageBuilder object which also acquires the same mutex. This mutex is not recursive, so during second acquirement, assertion fail is happening. Solution: LogRegExpSource should use the same MessageBuilder object as RegExpCompileEvent. Review URL: https://codereview.chromium.org/1207433002 Cr-Commit-Position: refs/heads/master@{#29347}
-
oth authored
BUG=505228 LOG=Y Review URL: https://codereview.chromium.org/1210153003 Cr-Commit-Position: refs/heads/master@{#29346}
-
machenbach authored
Revert of Use third_party clang on Mac. (patchset #4 id:60001 of https://codereview.chromium.org/1200833013/) Reason for revert: [Sheriff] Breaks mac on the main waterfall (though not on the tryserver): http://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/3925 Original issue's description: > Use third_party clang on Mac. > > BUG= > > Committed: https://crrev.com/57b20413294940476ab2b2e71ed0802aaf8c223f > Cr-Commit-Position: refs/heads/master@{#29343} TBR=danno@chromium.org,jkummerow@chromium.org,paul.lind@imgtec.com,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1217823003 Cr-Commit-Position: refs/heads/master@{#29345}
-
Michael Achenbach authored
Cr-Commit-Position: refs/heads/master@{#29344}
-
balazs.kilvady authored
BUG= Review URL: https://codereview.chromium.org/1200833013 Cr-Commit-Position: refs/heads/master@{#29343}
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1212163003 Cr-Commit-Position: refs/heads/master@{#29342}
-
machenbach authored
Make clang dir absolute to avoid differences between ninja and make gyp generator. BUG=chromium:502176 LOG=n Review URL: https://codereview.chromium.org/1217783002 Cr-Commit-Position: refs/heads/master@{#29341}
-
bmeurer authored
R=jarin@chromium.org Review URL: https://codereview.chromium.org/1218773002 Cr-Commit-Position: refs/heads/master@{#29340}
-
ben authored
Report builtins by name (e.g. "Builtin:ArgumentsAdaptorTrampoline") instead of labeling everything "Builtin:A builtin from the snapshot". BUG= Review URL: https://codereview.chromium.org/1216833002 Cr-Commit-Position: refs/heads/master@{#29339}
-
- 27 Jun, 2015 1 commit
-
-
machenbach authored
Fix c/p error from https://codereview.chromium.org/1217483002/ TBR=jochen@chromium.org Review URL: https://codereview.chromium.org/1214013002 Cr-Commit-Position: refs/heads/master@{#29338}
-
- 26 Jun, 2015 16 commits
-
-
dslomov authored
R=wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1212473002 Cr-Commit-Position: refs/heads/master@{#29337}
-
arv authored
Move class tests to es6 directory BUG=v8:3330 LOG=N R=adamk Review URL: https://codereview.chromium.org/1213813003 Cr-Commit-Position: refs/heads/master@{#29336}
-
mbrandy authored
Port 8a3cf4ec R=mvstanton@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1212613003 Cr-Commit-Position: refs/heads/master@{#29335}
-
arv authored
And move tests to es6 directory BUG=v8:3516 LOG=N R=adamk@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/1218473003 Cr-Commit-Position: refs/heads/master@{#29334}
-
mbrandy authored
Port 2b9112a5 Original commit message: This optimization is already implemented in fullcodegen, and basically makes sure that we do not unecessarily blow up the code with duplicated return sequences everywhere. R=bmeurer@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com BUG= Review URL: https://codereview.chromium.org/1218493003 Cr-Commit-Position: refs/heads/master@{#29333}
-
Erik Arvidsson authored
The test language/asi/S7.9_A5.7_T1 is failing intermittently. BUG=v8:4253 LOG=N TBR=adamk Review URL: https://codereview.chromium.org/1215813002. Cr-Commit-Position: refs/heads/master@{#29332}
-
dusan.milosavljevic authored
The use of jalr ra is unpredictable if instruction in branch delay slot is in next page. This finally fixes random failures in JS debugger and InteruptRequest tests. TEST=mjsunit/debug-*, cctest/test-api/RequestInterruptTestWithNativeAccessor BUG= Review URL: https://codereview.chromium.org/1220443002 Cr-Commit-Position: refs/heads/master@{#29331}
-
erikcorry authored
This is a step towards having Blink no longer look directly at the line endings array. That prevented https://codereview.chromium.org/1137683003/ from landing. Next step, after the roll, will be using these functions in Blink. R=jochen@chromium.org BUG= Review URL: https://codereview.chromium.org/1213783002 Cr-Commit-Position: refs/heads/master@{#29330}
-
arv authored
File bugs for all failing tests in test262-es6. There are still some old "needs investigation" failures that I didn't investigate. BUG=N LOG=N R=littledan@chromium.org, adamk@chromium.org Review URL: https://codereview.chromium.org/1209163002 Cr-Commit-Position: refs/heads/master@{#29329}
-
machenbach authored
BUG= Review URL: https://codereview.chromium.org/1217483002 Cr-Commit-Position: refs/heads/master@{#29328}
-
yangguo authored
Now that we keep tabs on shared function infos from a script, we can speed up finding shared function infos for debugging. However, in case we have to compile a function that cannot be lazily compiled without context, we fall back to the slow heap iteration. R=mstarzinger@chromium.org BUG=v8:4132,v8:4052 LOG=N Committed: https://crrev.com/cfe89a71a332ef9ed481c8210bc3ad6d2822034b Cr-Commit-Position: refs/heads/master@{#29296} Review URL: https://codereview.chromium.org/1206573004 Cr-Commit-Position: refs/heads/master@{#29327}
-
yangguo authored
Note that prior to having canonical shared function infos, this has been a source of duplicate shared function infos. R=bmeurer@chromium.org BUG=chromium:504787 LOG=N Review URL: https://codereview.chromium.org/1209383002 Cr-Commit-Position: refs/heads/master@{#29326}
-
vogelheim authored
BUG= Review URL: https://codereview.chromium.org/1205843005 Cr-Commit-Position: refs/heads/master@{#29325}
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1218443002 Cr-Commit-Position: refs/heads/master@{#29324}
-
machenbach authored
This reverts commit e93e4dad. BUG=chromium:502176 LOG=n NOTRY=true TBR=ulan@chromium.org, jochen@chromium.org Review URL: https://codereview.chromium.org/1213803002 Cr-Commit-Position: refs/heads/master@{#29323}
-
oth authored
v8 builds with --no-snap were hitting handle limits compiling natives for handle count unit tests that run with --check_handle_count. Patch now has higher handle limits (~4k more than required for failing natives compilation). Original issue: https://codereview.chromium.org/1185633002/ Original issue's description: > Additional HandleScopes to limit Handle consumption. > > erikcorry@chromium.org suggested digging into v8 handle usage. Found potential scopes in ast.cc and runtime-literals.cc and added tests. > > The runtime-literals.cc change reduces peak handles in imaging-darkroom.js from 1,282,610 to 428,218. The ast.cc change reduces the peak handles in string-t agcloud.js from 80,738 to 8,176. > > No significant handle count issues found with major websites, but substantial savings on some benchmarks and demos: > > Kraken's imaging-darkroom.js down from 1,282,610 to 428,218 due to runtime-literals.cc scope. > SunSpider's string-tagcloud.js down from 80,738 to 8.176 due to ast.cc > > http://www.flohofwoe.net/demos/dragons_asmjs.html (738,906 -> 478,296) > http://www.flohofwoe.net/demos/instancing_asmjs.html (737,884 -> 477,274) > https://dl.dropboxusercontent.com/u/16662598/Ports/DOSBox-web/doom.html?engine=dosbox-growth.js (1,724,114 -> 1,087,408) > https://kripken.github.io/ammo.js/examples/new/ammo.html (175,784 -> 142,058) > > BUG= > > Committed: https://crrev.com/3a4c7538839186aa38910c66c986abb563f4ccd2 > Cr-Commit-Position: refs/heads/master@{#29155} BUG= Review URL: https://codereview.chromium.org/1192743005 Cr-Commit-Position: refs/heads/master@{#29322}
-