Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#919 Apparent premature optimisation removes context and breaks signs

v0.9
closed-wont-fix
nobody
None
7
2013-01-29
2013-01-28
Jeremy Bloggs
No

Here is a tiny bit of code that I would expect to produce two 126s. This is because -3 is 253 as an 8-bit unsigned number, then 253/2 = 126.5, and division rounds toward zero. The reason I expect both divisions to be unsigned is that they are "context-determined" in standard speak (as opposed to "self-determined"), with the context being unsigned. Many thanks.

module trivial;

    reg we;
    reg [7:0] c;

    initial
            begin
                    c = 8'd3;
                    we = 1'b1;
                    $display ("res(we) = %d", (we ? (-$signed(c)) / 8'sd2 : 8'd1));
                    $display ("res(1)  = %d", (1'b1 ? (-$signed(c)) / 8'sd2 : 8'd1));
            end

endmodule

$ iverilog icarus.v && vvp.exe a.out
res(we) = 126
res(1)  =   -1

Discussion

  • Jeremy Bloggs
    Jeremy Bloggs
    2013-01-28

    Forgot to say: The version was 0.9.6 under Windows 7.

     
  • Cary R.
    Cary R.
    2013-01-28

    This works correctly using the latest development from git, but fails for the latest V0.9 from git and the V0.9.6 release. I'm switching this to a V0.9 bug and raising the priority since this is producing invalid results without a warning. Depending on the complexity of the fix this may not be fixable in the V0.9 branch. Steve has guidelines we try to follow regarding the scope of changes allowed in the stable branch.

     
  • Cary R.
    Cary R.
    2013-01-28

    • milestone: devel --> v0.9
    • priority: 5 --> 7
     
  • Cary R.
    Cary R.
    2013-01-29

    Unfortunately what fixed this in development is one of the significant changes that we are not going to back port to V0.9. Basically V0.9 does not have the sign information for the expressions until after they have been elaborated. The issue is that Icarus supports and some user are using code where for the special case of a constant select the unmatched branch is not elaborated. This allows constructs that are syntactically correct, but semantically incorrect to be skipped with a constant select. (e.g. a zero repeat concatenation). Development computes the sign information when it is calculating the width which is done before elaboration. This allows development to get the sign correct and skip elaborating the unselected branch.

    Since we will not be back porting the code I'm going to close this report as wont fix.

     
  • Cary R.
    Cary R.
    2013-01-29

    • status: open --> closed-wont-fix