58ab990aa8
The LoadBuffer operator that is used for asm.js heap access claims to return only the appropriate typed array type, but out of bounds access could make it return undefined. So far we tried to "repair" the graph later if we see that our assumption was wrong, and for various reasons that worked for some time. But now that wrong type information that is propagated earlier is picked up appropriately and thus we generate wrong code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and thus get 2147483648 instead of 0 (with proper JS truncation). This was always considered a temporary hack until we have a proper asm.js pipeline, but since we still run asm.js through the generic JavaScript pipeline, we have to address this now. Quickfix is to just bailout from the pipeline when we see that the LoadBuffer type was wrong, i.e. the result of LoadBuffer is not properly truncated and thus undefined or NaN would be observable. R=mstarzinger@chromium.org, jarin@chromium.org BUG=chromium:589792 LOG=y Review URL: https://codereview.chromium.org/1740123002 Cr-Commit-Position: refs/heads/master@{#34322}
21 lines
617 B
JavaScript
21 lines
617 B
JavaScript
// Copyright 2016 the V8 project authors. All rights reserved.
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
// found in the LICENSE file.
|
|
|
|
// Flags: --allow-natives-syntax
|
|
|
|
var boom = (function(stdlib, foreign, heap) {
|
|
"use asm";
|
|
var MEM8 = new stdlib.Uint8Array(heap);
|
|
var MEM32 = new stdlib.Int32Array(heap);
|
|
function foo(i, j) {
|
|
j = MEM8[256];
|
|
// This following value '10' determines the value of 'rax'
|
|
MEM32[j >> 10] = 0xabcdefaa;
|
|
return MEM32[j >> 2] + j
|
|
}
|
|
return foo
|
|
})(this, 0, new ArrayBuffer(256));
|
|
%OptimizeFunctionOnNextCall(boom);
|
|
boom(0, 0x1000);
|