trap on divide by zero?

[binji]

(module
  (func
    (i32.div_s (i32.const 1) (i32.const 0)))
  (export "f" 0))
(invoke "f")

This traps in the spec repo, but succeeds in v8-native-prototype.

[jfbastien]

I looked it up to make sure we specified this behavior. c.f. design repo behavior on trap:

Signed and unsigned operations trap whenever the result cannot be represented in the result type. This includes division and remainder by zero, and signed division overflow (INT32_MIN / -1). Signed remainder with a non-zero denominator always returns the correct value, even when the corresponding division would trap. Sign-agnostic operations silently wrap overflowing results into the result type.

[titzer]

Yep, v8-native-prototype doesn't trap, it does the asm.js things, for this
and out-of-bounds accesses. Can you create an issue on GitHub to track
these?

Known issues:

• int32_div and int32_mod should trap on 0 denom
• floating point conversions do JS semantics
• out-of-bounds memory accesses should trap

On Tue, Sep 29, 2015 at 1:04 AM, JF Bastien notifications@github.com
wrote:

I looked it up to make sure we specified this behavior. c.f. design repo
behavior
https://github.com/WebAssembly/design/blob/master/AstSemantics.md#32-bit-integer-operations
on trap:

Signed and unsigned operations trap whenever the result cannot be
represented in the result type. This includes division and remainder by
zero, and signed division overflow (INT32_MIN / -1). Signed remainder
with a non-zero denominator always returns the correct value, even when the
corresponding division would trap. Sign-agnostic operations silently wrap
overflowing results into the result type.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[titzer]

Also, shifts implicitly mask the right-hand size, and should do a range
check.

On Tue, Sep 29, 2015 at 2:13 AM, Ben L. Titzer titzer@google.com wrote:

Yep, v8-native-prototype doesn't trap, it does the asm.js things, for this
and out-of-bounds accesses. Can you create an issue on GitHub to track
these?

Known issues:

• int32_div and int32_mod should trap on 0 denom
• floating point conversions do JS semantics
• out-of-bounds memory accesses should trap

On Tue, Sep 29, 2015 at 1:04 AM, JF Bastien notifications@github.com
wrote:

I looked it up to make sure we specified this behavior. c.f. design repo
behavior
https://github.com/WebAssembly/design/blob/master/AstSemantics.md#32-bit-integer-operations
on trap:

Signed and unsigned operations trap whenever the result cannot be
represented in the result type. This includes division and remainder by
zero, and signed division overflow (INT32_MIN / -1). Signed remainder
with a non-zero denominator always returns the correct value, even when the
corresponding division would trap. Sign-agnostic operations silently wrap
overflowing results into the result type.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[sunfishcode]

Note that the spec repo's conversion operators aren't quite aligned with the design repo yet; WebAssembly/spec#87 fixes the remaining known issues.

[binji]

Interestingly, this actually crashes:

(module
  (func (result i32)
    (i32.select (i32.const 1)
      (i32.div_s (i32.const 1) (i32.const 0))
      (i32.const 1)))
  (export "f" 0))
(invoke "f")

with:

$ third_party/v8-native-prototype/v8/v8/out/Debug/d8 test/spec.js dz.js 
Floating point exception (core dumped)

[titzer]

Yeah, not generating zero checks yet :-/

On Mon, Nov 9, 2015 at 3:23 PM, Ben Smith notifications@github.com wrote:

Interestingly, this actually crashes:

(module
(func (result i32)
(i32.select (i32.const 1)
(i32.div_s (i32.const 1) (i32.const 0))
(i32.const 1)))
(export "f" 0))
(invoke "f")

with:

$ third_party/v8-native-prototype/v8/v8/out/Debug/d8 test/spec.js dz.js
Floating point exception (core dumped)

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[titzer]

This was implemented in 17323bd