#919 Apparent premature optimisation removes context and breaks signs


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;

                    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));


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


  • 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

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks