- 26 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This way, we can also check the return code of d8. We currently have a bug (6981) which makes failing tests not being detected, even though the failure message is (sometimes) being printed. After this refactoring, we can write tests for our mjsunit test functions. R=machenbach@chromium.org Bug: v8:6981 Change-Id: I0aa0abcb0f9a4f622a1e1d1a4d826da1e6eb4f07 Reviewed-on: https://chromium-review.googlesource.com/737991Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48951}
-
- 12 Dec, 2016 1 commit
-
-
clemensh authored
The current logic in Isolate::GetLocationFromStackTrace just ignores wasm frames, making the computed location point to the first javascript frame, like this: test.js:17: RuntimeError: divide by zero module.exports.main(); ^ RuntimeError: divide by zero at main (<WASM>[1]+5) at test.js:17:16 This CL not only fixes the location to point to the top-most wasm frame, but also exposes to the embedder that the script of that location is a wasm script, allowing for custom printing of wasm locations. The Shell::ReportException method now checks for this flag, and prints wasm locations like this: <WASM>[0]+5: RuntimeError: divide by zero RuntimeError: divide by zero at main (<WASM>[0]+5) at test/message/wasm-trap.js:15:16 R=titzer@chromium.org, yangguo@chromium.org BUG=chromium:613110 Review-Url: https://codereview.chromium.org/2563673002 Cr-Commit-Position: refs/heads/master@{#41640}
-
- 21 Nov, 2016 1 commit
-
-
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}
-
- 13 Oct, 2016 2 commits
-
-
ahaas authored
A decoder error sets builder_ to null, which causes builder_->StackCheck to segfault. R=titzer@chromium.org TEST=mjsunit/regress/wasm/loop-stack-check Review-Url: https://codereview.chromium.org/2416873002 Cr-Commit-Position: refs/heads/master@{#40271}
-
ahaas authored
BUG=chromium:654377 TEST=mjsunit/regress/wasm/regression-654377 R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2403013002 Cr-Commit-Position: refs/heads/master@{#40246}
-
- 05 Oct, 2016 3 commits
-
-
ahaas authored
The implementation of MemorySize with RelocatableInt32Constants is problematic if MemorySize is placed close to a GrowMemory instruction in the code. The use of a runtime function guarantees that the order in which MemorySize and GrowMemory is executed is correct. R=titzer@chromium.org BUG=chromium:651961 TEST=mjsunit/regress/wasm/regression-651961 Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689 Review-Url: https://codereview.chromium.org/2386183004 Cr-Original-Commit-Position: refs/heads/master@{#39972} Cr-Commit-Position: refs/heads/master@{#39980}
-
ahaas authored
Revert of [wasm] Call a runtime function for a MemorySize instruction. (patchset #2 id:20001 of https://codereview.chromium.org/2386183004/ ) Reason for revert: Patch problem Original issue's description: > [wasm] Call a runtime function for a MemorySize instruction. > > The implementation of MemorySize with RelocatableInt32Constants is > problematic if MemorySize is placed close to a GrowMemory instruction in > the code. The use of a runtime function guarantees that the order in > which MemorySize and GrowMemory is executed is correct. > > R=titzer@chromium.org > BUG=chromium:651961 > TEST=mjsunit/regress/wasm/regression-651961 > > Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689 > Cr-Commit-Position: refs/heads/master@{#39972} TBR=titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:651961 Review-Url: https://codereview.chromium.org/2391223002 Cr-Commit-Position: refs/heads/master@{#39973}
-
ahaas authored
The implementation of MemorySize with RelocatableInt32Constants is problematic if MemorySize is placed close to a GrowMemory instruction in the code. The use of a runtime function guarantees that the order in which MemorySize and GrowMemory is executed is correct. R=titzer@chromium.org BUG=chromium:651961 TEST=mjsunit/regress/wasm/regression-651961 Review-Url: https://codereview.chromium.org/2386183004 Cr-Commit-Position: refs/heads/master@{#39972}
-