#913 Crash:Passing an inverted signal to a user-defined primitive

v0.9
closed
nobody
5
2013-01-22
2012-11-15
No

Icarus verilog seems to crash if a signal in the parameter list of an instanced user-defined primitive has an inverted signal.

See the following script for complete reproduction steps:

$ iverilog -v
Icarus Verilog version 0.9.5 (v0_9_5)
$ cat <<EOF >primtest.v

primitive passthrough (o, i);
input i;
output o;
table
// i : o
1 : 1;
0 : 0;
? : 0;
endtable
endprimitive

module passing_module (o, i);
input i;
output o;

passthrough (o, !i);
endmodule

module failing_module (o, i);
input i;
output o;

passthrough (o, !i);
endmodule
EOF
$ iverilog primtest.v
primtest.v:24: assert: elab_expr.cc:3706: failed assertion expr_type_ != IVL_VT_NO_TYPE
sh: line 1: 25881 Done /usr/lib64/ivl/ivlpp -L -F"/tmp/ivrlg23e8c518f" -f"/tmp/ivrlg3e8c518f" -p"/tmp/ivrli3e8c518f"
25882 Aborted | /usr/lib64/ivl/ivl -C"/tmp/ivrlh3e8c518f" -C"/usr/lib64/ivl/vvp.conf" -- -

Note that the 'passing_module' parsed, but the 'failing_module' caused a compiler error

Discussion

  • Gah - bad cut & paste. Change line 17 from to 'passthrough (o , i), otherwise the failure will be on line 17.

     
  • Cary R.
    Cary R.
    2012-11-15

    Modified test file

     
    Attachments
  • Cary R.
    Cary R.
    2012-11-15

    I have verified that this problem still exists in the V0.9.6 release, but it is fixed in the latest development (v0.10). I've attached a modified version of the test code which shows that both ! and ~ fail and is test suite friendly. I did not try more complicated expression, but I would assume they may also have problems.

     
  • Thanks - updating to iverilog's master branch (revision f01a106c25e7a467a104ffae74624d1b3574738b) clears this issue for me.

    If it's a trivial fix, it would be nice to have this backported to 0.9.x, otherwise feel free to close this once the regression test is checked in.

     
  • Cary R.
    Cary R.
    2012-11-15

    How fixes in a stable branch (currently V0.9) are normally handled is we only try to fix the problem if it doesn't risk changing the behavior/output in some other way. So yes, we will see if this can be fixed in what will become v0.9.7, but if it is too complicated this report will be closed as out of date.

    FYI in general development (v0.10) is stable enough for real world work. It does occasionally have periods of instability, but these are usually short lived (hours or days).

     
  • I have posted a patch on the patch tracker to fix this bug.

    Steve/Cary - I seem to have lost the rights to change the status of bugs in the move to the new SourceForge system, so please close this for me.

     
  • Cary R.
    Cary R.
    2013-01-22

    • status: open --> closed
     
  • Cary R.
    Cary R.
    2013-01-22

    I have applied and pushed the patch. It is available from git and the next V0.9 release whenever that happens.