HWMemSimImplPass crashes with SIGFPE on zero-width memory when -disable-opt is used

[benreynwar]

The following bug report was generated by Claude.
I'm fairly confident it's not nonsense.

Claude generated report

firtool crashes with a floating point exception (SIGFPE) in HWMemSimImplPass when processing a cmem with zero-width data type (UInt<0>) and -disable-opt is passed. Without -disable-opt, the optimizer removes the zero-width memory before the pass runs, so the crash doesn't occur.

Reproduces on firtool 1.128.0 and 1.142.0.

Minimal reproducer (repro.fir):

  FIRRTL version 4.0.0
  circuit MinRepro :
    public module MinRepro :
      input clock : Clock
      input reset : UInt<1>
      input addr : UInt<2>
      input wdata : UInt<0>
      input wen : UInt<1>
      output rdata : UInt<0>

      cmem ram : UInt<0>[4]
      when wen :
        infer mport wr = ram[addr], clock
        connect wr, wdata
      infer mport rd = ram[addr], clock
      connect rdata, rd

To reproduce:
firtool repro.fir -format=fir -disable-opt

Stack trace (1.142.0):
#4 (anonymous namespace)::HWMemSimImplPass::runOnOperation() HWMemSimImpl.cpp:0:0

Context: This can be hit in practice when Chisel generates a Queue(UInt(0.W), n), which produces a cmem with zero-width elements. For example, Queue(UInt(log2Ceil(1).W), 4) produces UInt<0>.

Human comments

When I ran the minimal reproducer myself I got:

ben@ironmonger:~/Code/deleteme$ /tmp/firtool-latest/firtool-1.142.0/bin/firtool repro.fir -format=fir -disable-opt
PLEASE submit a bug report to https://github.com/llvm/circt and include the crash backtrace.
Stack dump:
0.      Program arguments: /tmp/firtool-latest/firtool-1.142.0/bin/firtool repro.fir -format=fir -disable-opt
 #0 0x00007f5645006a28 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/tmp/firtool-latest/firtool-1.142.0/bin/../lib/libLLVMSupport.so+0x206a28)
 #1 0x00007f5645004485 llvm::sys::RunSignalHandlers() (/tmp/firtool-latest/firtool-1.142.0/bin/../lib/libLLVMSupport.so+0x204485)
 #2 0x00007f56450077b1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0
 #3 0x00007f5644a45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330)
 #4 0x00007f56472eb97c (anonymous namespace)::HWMemSimImplPass::runOnOperation() HWMemSimImpl.cpp:0:0
 #5 0x00007f5645c9e7c7 mlir::detail::OpToOpPassAdaptor::run(mlir::Pass*, mlir::Operation*, mlir::AnalysisManager, bool, unsigned int) (/tmp/firtool-latest/firtool-1.142.0/bin/../lib/libMLIRPass.so+0x177c7)
 #6 0x00007f5645ca17e9 mlir::PassManager::run(mlir::Operation*) (/tmp/firtool-latest/firtool-1.142.0/bin/../lib/libMLIRPass.so+0x1a7e9)
 #7 0x000055f626f2afaa processBuffer(mlir::MLIRContext&, circt::firtool::FirtoolOptions&, mlir::TimingScope&, llvm::SourceMgr&, std::optional<std::unique_ptr<llvm::ToolOutputFile, std::default_delete<llvm::ToolOutputFile>>>&) firtool.cpp:0:0
 #8 0x000055f626f29951 processInputSplit(mlir::MLIRContext&, circt::firtool::FirtoolOptions&, mlir::TimingScope&, std::unique_ptr<llvm::MemoryBuffer, std::default_delete<llvm::MemoryBuffer>>, std::optional<std::unique_ptr<llvm::ToolOutputFile, std::default_delete<llvm::ToolOutputFile>>>&) firtool.cpp:0:0
 #9 0x000055f626f25989 executeFirtool(mlir::MLIRContext&, circt::firtool::FirtoolOptions&) firtool.cpp:0:0
#10 0x000055f626f2437f main (/tmp/firtool-latest/firtool-1.142.0/bin/firtool+0x1237f)
#11 0x00007f5644a2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#12 0x00007f5644a2a28b call_init ./csu/../csu/libc-start.c:128:20
#13 0x00007f5644a2a28b __libc_start_main ./csu/../csu/libc-start.c:347:5
#14 0x000055f626f20415 _start (/tmp/firtool-latest/firtool-1.142.0/bin/firtool+0xe415)
Floating point exception (core dumped)

Also when I removed the zero-width Queues in my chisel the crash went away.

[seldridge]

Thanks for the bug report. Still reproducible on 1.144.0. Yeah, this is a real issue and can come up, as you mention, with generators and not special-casing the zero-width case (which Chisel doesn't encourage designers to do).

I expect that HWMemSimImpl just doesn't know what to do when it sees a memory with zero-width data. I expect the right thing is to just delete it (which is assumedly what is going on when optimizations are enabled).