Re: [Iverilog-devel] oddity in reproducing pr1879226

[Larry D. <ldo...@re...>]

On Tue, Jan 29, 2008 at 06:44:25PM -0800, Larry Doolittle wrote:
> Bet'cha nickel your tests passed on a 64-bit machine.  I attach the
> input file, and _different_ -t stub output file from two machines, one
> showing the error, the other not.  The command in both cases is simply
>    iverilog uwe.v -t stub
> The most meaningful difference between the two is 32 vs. 64 bitness.
> The iverilog in both cases is freshly compiled from current git, but
> with patch 1881942 disabled.

I detect sloppiness in the use of int vs. long.

The offending NetNet was created by the buggy shift elaborator
with npins=0.  A NetNet's msb_ is initialized to npins-1, where npins
is unsigned, and therefore npins-1 = 0xffffffff = 4294967295.  msb_ is
declared long, so this result after cast is interpreted as 0x00000000ffffffff
(4294967295) on a 64-bit machine, but 0xffffffff (-1) on a 32-bit machine.

Line 2151 of t-dll.cc is
      obj->width_ = net->vector_width();
where obj->width_ is declared unsigned (t-dll.h:576),
but net->vector_width() is unsigned long (netlist.h:504).
In the 64-bit case, the msb_ > lsb_ width calculation performed in
vector_width() (netlist.cc:632) is 4294967295-0+1=4294967296,
which yields 0 after the cast to unsigned.  In the 32-bit case,
msb_ > lsb_ is false (-1 is not > 0), so the width calculation
(netlist.cc:634) is 0-(-1)+1=2, cast to unsigned is still 2.

My new assert(npins>0) for NetNet will obviously help.  I'm not sure
what other changes, if any, are called for.

   - Larry