Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzer: Segfault on genvar out of scope #1589

Closed
veripoolbot opened this issue Nov 4, 2019 · 2 comments
Closed

Fuzzer: Segfault on genvar out of scope #1589

veripoolbot opened this issue Nov 4, 2019 · 2 comments
Assignees
Labels
area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed

Comments

@veripoolbot
Copy link
Contributor


Author Name: Eric Rippey
Original Redmine Issue: 1589 from https://www.veripool.org

Original Assignee: Wilson Snyder (@wsnyder)


Running the attached testcase with:

verilator_bin --lint-only 7.sv

On version:

Verilator 4.020 devel rev v4.020-56-gbcb766b

Produces:

%Error: 7.sv:16: Unsupported: Member call on non-enum object 'VARREF 'j'' which is a 'BASICDTYPE 'integer''
                : ... In instance t
  j.e(0),
     ^
Segmentation fault (core dumped)

I think there are two different problems here:

  1. Shouldn't the "j" be inaccessible at all because it should only exist in the scope of the generate block in which it's defined?
  2. Even if "j" is switched to be declared within the module as "integer j;" the segfault still persists.
@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-05T02:16:18Z


Generate dosn't make a scope, begin/end does. Basically generate was a Verilog 2001 thing now not needed.

Cleaned up warnings & real issue.

Fixed in git towards 4.022.

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Eric Rippey
Original Date: 2019-11-06T00:35:26Z


Regarding the scope: that's interesting. I think you're right but it took me longer to confirm that than I expected. I didn't find anything definitive either way in the standard, and so I tried running:

module a;
  initial $display("a=",a);
  generate
     genvar a;
  endgenerate
endmodule

with ModelSim and it choked because it didn't want to let the genvar be accessible there. Then I tried iverilog and it choked because it couldn't handle printing a genvar at all. And then I tried:

module a;
  initial $display("a=",a);
  generate
     integer a;
  endgenerate
endmodule

And they both accepted it. Meanwhile, Verilator seems to treat these two cases the same, which seems like the correct thing to do.

@veripoolbot veripoolbot added area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed labels Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: lint Issue involves SystemVerilog lint checking resolution: fixed Closed; fixed
Projects
None yet
Development

No branches or pull requests

2 participants