- 22 Nov, 2016 33 commits
-
-
mtrofin authored
Previous fuzzer fix broke the case when the pending assessment came from the same block. In that case, the assessments table does not have an entry yet for the block, because we register only when we're done processing a block. BUG=667745 Review-Url: https://codereview.chromium.org/2519973004 Cr-Commit-Position: refs/heads/master@{#41193}
-
clemensh authored
We had error messages that exceeded the current limit of 100 characters, resulting in the newline being cut off. This CL also reverts http://crrev.com/2503423006 since it did not fix this issue. BUG=chromium:660016 R=machenbach@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2523703002 Cr-Commit-Position: refs/heads/master@{#41192}
-
clemensh authored
The GetPositionInfo function only operates on WasmCompiledModule, so it should be a method of that class. This CL also splits the method in two, such that I can reuse the GetContainingFunction method for breakpoint support. R=titzer@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2521293002 Cr-Commit-Position: refs/heads/master@{#41191}
-
ahaas authored
Wrapper creation for import functions with i64 return values on 32-bit platforms crashed because the number of return values of the wrapper did not match the number of input nodes of the return node. The issue is fixed by not creating special wrappers for 32-bit platforms in the first place. This is valid because wrappers with i64 return values are never actually executed. R=titzer@chromium.org BUG=v8:5661 Review-Url: https://codereview.chromium.org/2517173003 Cr-Commit-Position: refs/heads/master@{#41190}
-
marja authored
The tests were relying on early errors which we don't produce since we now preparse more often. BUG=v8:2728, v8:5501, v8:5663 Review-Url: https://codereview.chromium.org/2523683002 Cr-Commit-Position: refs/heads/master@{#41189}
-
jkummerow authored
The handwritten-assembly implementations of both dispatcher and generic stub have been replaced by Turbofan-generated stubs. Review-Url: https://codereview.chromium.org/2523473002 Cr-Commit-Position: refs/heads/master@{#41188}
-
jkummerow authored
Reducing visual clutter. Review-Url: https://codereview.chromium.org/2519093002 Cr-Commit-Position: refs/heads/master@{#41187}
-
hpayer authored
BUG=chromium:667388 Review-Url: https://codereview.chromium.org/2521983002 Cr-Commit-Position: refs/heads/master@{#41186}
-
jkummerow authored
For dictionary-mode receivers, the KeyedStoreGeneric stub can store properties directly in most cases. Doing so avoids the need to have an entry in the stub cache for every map/property combination. Review-Url: https://codereview.chromium.org/2504403005 Cr-Commit-Position: refs/heads/master@{#41185}
-
ulan authored
BUG=chromium:667388 Review-Url: https://codereview.chromium.org/2520963004 Cr-Commit-Position: refs/heads/master@{#41184}
-
marja authored
... but be less pessimistic about context allocation (see below). We might have just (pessimistically) context-allocated a variable based on references coming from an inner function, but after that we still need to set maybe_assigned (pessimistically). This makes test-parsing/InnerAssignment pass with FLAG_lazy_inner_functions. This was undetected until now because we didn't have lazy parsing enabled for small scripts. Less pessimistic approach: now that inner functions laziness decisions are stable (if we have once compiled a piece of code with lazy inner functions, we never compile the same code with eager inner functions), we don't need to be as pessimistic with context allocation as before. BUG=v8:5501 Review-Url: https://codereview.chromium.org/2521513004 Cr-Commit-Position: refs/heads/master@{#41183}
-
jgruber authored
Wasm frames are special in that they have a non-integer script id in inspector. The way we treat script ids currently is a bit of a mess - our runtime functions expected integer IDs while inspector has string IDs (which contain integers, except for Wasm frames). This will need to be cleaned up once more Wasm tests are added. The meaning of line/column numbers has also changed; the old JS debug API encoded the function index and byte offset into line/column numbers, while inspector-based API actually translates into lines/columns in the disassembly. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2515133003 Cr-Commit-Position: refs/heads/master@{#41182}
-
mstarzinger authored
This makes sure the {kScratchRegister} is not used across macro instructions (e.g. {LeaveFrame}) that would clobber its content. Generally it is highly unsafe to use such scratch registers with a life-range spanning macro instructions. R=neis@chromium.org Review-Url: https://codereview.chromium.org/2521973002 Cr-Commit-Position: refs/heads/master@{#41181}
-
neis authored
TBR=littledan@chromium.org BUG= Review-Url: https://codereview.chromium.org/2517143003 Cr-Commit-Position: refs/heads/master@{#41180}
-
jgruber authored
Unfortunately, there's currently no satisfying way of accessing scopes of suspended generator objects through inspector. This CL implements access to such scopes through runtime functions instead. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2513343004 Cr-Commit-Position: refs/heads/master@{#41179}
-
verwaest authored
This makes the test in the bug ~10x faster. It could inadvertently make other things slower, so revert eagerly if included in a range where performance tanks. BUG=chromium:666852 Review-Url: https://codereview.chromium.org/2525573002 Cr-Commit-Position: refs/heads/master@{#41178}
-
jgruber authored
StepFrame is a combination of StepIn/StepOut, e.g. it breaks to the next frame change. This is not part of the public API, but we want to keep it for internal tests. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2514303003 Cr-Commit-Position: refs/heads/master@{#41177}
-
ahaas authored
With this CL the regexp-parser-fuzzer uses the first byte of the fuzzer input to select the regexp flag instead of executing each input with all possible flags. Thereby the fuzzer can explore more inputs and with its coverage metric will explore all flags only for interesting inputs. I updated all files in test/fuzzer/regexp and added a random byte at the beginning. This byte is used by the fuzzer to determine the flag. BUG=chromium:664436 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2511373002 Cr-Commit-Position: refs/heads/master@{#41176}
-
jgruber authored
* Fix setting script-scope variables through inspector by internalizing their names. * Reconstruct values of Number, String, and Boolean classes. * Adapt a couple of tests for API restrictions. BUG=v8:5530 Review-Url: https://codereview.chromium.org/2512963002 Cr-Commit-Position: refs/heads/master@{#41175}
-
titzer authored
BUG=chromium:667603 R=clemensh@chromium.org Review-Url: https://codereview.chromium.org/2519363002 Cr-Commit-Position: refs/heads/master@{#41174}
-
jarin authored
BUG=chromium:664117 Review-Url: https://codereview.chromium.org/2522883002 Cr-Commit-Position: refs/heads/master@{#41173}
-
clemensh authored
When disassembling functions for the inspector, we used an internal text representation before. This CL implements the official text format like it is understood by the spec interpreter. Example output: func $main (param i32) (result i32) block i32 get_local 0 i32.const 2 i32.lt_u if i32.const -2 return end get_local 0 call_indirect 0 end R=rossberg@chromium.org, titzer@chromium.org BUG=chromium:659715 Review-Url: https://codereview.chromium.org/2520943002 Cr-Commit-Position: refs/heads/master@{#41172}
-
mstarzinger authored
R=neis@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2523693002 Cr-Commit-Position: refs/heads/master@{#41171}
-
mstarzinger authored
This fixes stack unwinding to always recompute the stack pointer for interpreted frames. For frames materialized by the deoptimizer we elide the handler frame in between, hence arguments being pushed on the stack will no longer be pushed into the handler frame but into the interpreted frame directly. R=jarin@chromium.org TEST=mjsunit/regress/regress-crbug-662830 BUG=chromium:662830 Review-Url: https://codereview.chromium.org/2517203003 Cr-Commit-Position: refs/heads/master@{#41170}
-
bmeurer authored
BUG=chromium:667689 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2518313002 Cr-Commit-Position: refs/heads/master@{#41169}
-
tebbi authored
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 Review-Url: https://codereview.chromium.org/2503393002 Cr-Commit-Position: refs/heads/master@{#41168}
-
cbruni authored
R=hablich@chromium.org NOTRY=true NOTREECHECKS=true Review-Url: https://codereview.chromium.org/2514283003 Cr-Commit-Position: refs/heads/master@{#41167}
-
bmeurer authored
TurboFan can indeed comsume NumberOrOddball feedback for abstract relational comparisons, so we should just provide it from Ignition. Drive-by-fix: Add a DCHECK to protect against abstract/strict equality number comparison accidentially utilizing Oddball feedback. BUG=v8:5267,v8:5400 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2518283002 Cr-Commit-Position: refs/heads/master@{#41166}
-
jbroman authored
This code should not access bytes out of the permitted range in order to check the range of a possible UTF-8 value. Instead, the length check should occur before such checks. BUG=chromium:667260, chromium:662822 Review-Url: https://codereview.chromium.org/2520053003 Cr-Commit-Position: refs/heads/master@{#41165}
-
yangguo authored
R=jshin@chromium.org Review-Url: https://codereview.chromium.org/2514333002 Cr-Commit-Position: refs/heads/master@{#41164}
-
bmeurer authored
Make use of the previously introduced String feedback for compare operations in TurboFan. R=jarin@chromium.org BUG=v8:5267,v8:5400 Review-Url: https://codereview.chromium.org/2523463002 Cr-Commit-Position: refs/heads/master@{#41163}
-
kozyatinskiy authored
BUG=none R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2505823002 Cr-Commit-Position: refs/heads/master@{#41162}
-
pfeldman authored
BUG=chromium:651324 Review-Url: https://codereview.chromium.org/2522593005 Cr-Commit-Position: refs/heads/master@{#41161}
-
- 21 Nov, 2016 7 commits
-
-
gdeepti authored
- Simd Scalar lowering should be conditionally disabled if the architecture has a native SIMD implementation. - Enable scalar lowering tests on all architectures instead of only x64. R=bbudge@chromium.org, aseemgarg@chromium.org Review-Url: https://codereview.chromium.org/2514663002 Cr-Commit-Position: refs/heads/master@{#41160}
-
mtrofin authored
The verifier needs to use the block and assessments in that block corresponding to a predecessor of a "pending" assessment. Not doing that causes incorrect assessments when 2 locations are swapped. BUG=665402 Review-Url: https://codereview.chromium.org/2515803002 Cr-Commit-Position: refs/heads/master@{#41159}
-
eholk authored
This fixes a bug found by the fuzzer where we would attempt to dereference a null handle if memory allocation failed. In this case, the failure was because the amount of memory requested was above V8's hardcoded limit. BUG= https://bugs.chromium.org/p/chromium/issues/detail?id=666741 Review-Url: https://codereview.chromium.org/2514983002 Cr-Commit-Position: refs/heads/master@{#41158}
-
fedor authored
Export JS_API_OBJECT_TYPE, JS_SPECIAL_API_OBJECT_TYPE. Exports JSObject::kHeaderSize to ease the inspection of internal fields in llnode. BUG= R=machenbach Review-Url: https://codereview.chromium.org/2514063002 Cr-Commit-Position: refs/heads/master@{#41157}
-
thestig authored
Instead of directly using v8_enable_inspector_override from build_overrides/v8.gni in all the GN configs, set a v8_enable_inspector variable based on v8_enable_inspector_override and use that everywhere. This is the more common pattern seen in over projects, and reduces the need to include //build_overrides/v8.gni in many files. Review-Url: https://codereview.chromium.org/2520683002 Cr-Commit-Position: refs/heads/master@{#41156}
-
ahaas authored
R=titzer@chromium.org CC=mtrofin@chromium.org Review-Url: https://codereview.chromium.org/2520853003 Cr-Commit-Position: refs/heads/master@{#41155}
-
titzer authored
R=mstarzinger@chromium.org,clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2520963002 Cr-Commit-Position: refs/heads/master@{#41154}
-