yunligou711-commits opened a new issue, #20400:
URL: https://github.com/apache/tvm/issues/20400

   Thanks for participating in the TVM community! We use 
https://discuss.tvm.apache.org/ for any general usage questions and 
discussions. The issue tracker is used for actionable items such as feature 
proposals discussion, roadmaps, and bug tracking. You are always welcomed to 
post on the forum first :smile_cat:
   
   ### Expected behavior
   
   `relax.floor_divide` (and `relax.divide`) on integer tensors should have a 
**defined**
   behaviour for a zero divisor — either a documented result, or a raised TVM 
error at
   execution time.
   
   What it should not do is kill the host process: a single zero element in the 
input makes
   the compiled module un-runnable, and there is no way for the caller to catch 
or recover
   from it.
   
   ### Actual behavior
   
   The integer `//` is lowered to LLVM `sdiv`. On x86-64 `sdiv` raises `#DE`, 
which the
   kernel delivers as `SIGFPE`, terminating the process:
   
   $ python repro.py
   === 3. run with y != 0 (expect fine) ===
   output[0][:5]: [4 0 0 0 0]
   
   === 4. run with y containing 0 (the fuzzer-generated input) ===
   y has zeros: True
   about to execute integer division by zero ...
   Floating point exception (core dumped)      # exit code 136 / SIGFPE
   
   
   
   No TVM error, no Python exception — the interpreter is gone.
   
   ### Environment
   
   Same as the companion non-float-`DivNode` report:
   - TVM version: `0.26.dev0`, commit `8312a17f8734ddfd56e5f3977cd5df25b83ec49f`
   - OS: Ubuntu 20.04.6 LTS, kernel 5.15.0-139-generic, gcc 13.1.0
   - Target: `llvm` (host), CPU: Intel Xeon Gold 6326
   
   ### Triage
   needs-triage
   ### Bug
   target: llvm
   Please follow this repository's security policy and code of conduct.
   ### Steps to reproduce
   
   ```python
   import numpy as np
   import tvm
   from tvm import relax
   from tvm.script import ir as I
   from tvm.script import tirx as T
   from tvm.script import relax as R
   
   
   @I.ir_module
   class Module:
       @T.prim_func(private=True, s_tir=True)
       def floor_divide(
           x: T.Buffer((T.int64(27), T.int64(61)), "int64"),
           y: T.Buffer((T.int64(27), T.int64(61)), "int64"),
           T_floor_divide: T.Buffer((T.int64(27), T.int64(61)), "int64"),
       ):
           T.func_attr({"tir.noalias": T.bool(True)})
           for ax0, ax1 in T.grid(T.int64(27), T.int64(61)):
               with T.sblock("T_floor_divide"):
                   v_ax0, v_ax1 = T.axis.remap("SS", [ax0, ax1])
                   T.reads(x[v_ax0, v_ax1], y[v_ax0, v_ax1])
                   T.writes(T_floor_divide[v_ax0, v_ax1])
                   T_floor_divide[v_ax0, v_ax1] = x[v_ax0, v_ax1] // y[v_ax0, 
v_ax1]
   
       @R.function
       def main(
           x: R.Tensor((27, 61), dtype="int64"), y: R.Tensor((27, 61), 
dtype="int64")
       ) -> R.Tensor((27, 61), dtype="int64"):
           R.func_attr({"num_input": 1})
           cls = Module
           with R.dataflow():
               gv_1 = R.call_tir(cls.floor_divide, (x, y), out_ty=R.Tensor((27, 
61), dtype="int64"))
               R.output(gv_1)
           return gv_1
   
   
   mod = Module
   with tvm.transform.PassContext(disabled_pass=["RemoveUnusedParameters"]):
       mod = relax.transform.FuseTIR()(mod)
   mod = relax.transform.LegalizeOps()(mod)
   mod = relax.transform.LambdaLift()(mod)
   with tvm.transform.PassContext(opt_level=4):
       ex = relax.build(mod, target="llvm")
   
   vm = relax.VirtualMachine(ex, tvm.cpu())
   
   x = tvm.runtime.tensor(np.random.randint(10, size=(27, 61)).astype("int64"))
   y = tvm.runtime.tensor(np.random.randint(10, size=(27, 61)).astype("int64"))
   
   vm["main"](x, tvm.runtime.tensor(np.ones((27, 61), dtype="int64") * 2))  # 
fine
   vm["main"](x, y)                                                        # 
SIGFPE
   How this was found: same differential-testing fuzzer as above; ~42 generated 
modules hit
   this. Note this is a different failure from the non-float-DivNode report — 
both are
   about division not being handled defensively, but this one is a runtime trap 
in
   CreateSDiv, not a compile-time ICHECK.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to