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

Statement label should be allowed to be a duplicate of a parameter #1603

Closed
veripoolbot opened this issue Nov 15, 2019 · 2 comments
Closed
Labels
resolution: wontfix Closed; work won't continue on an issue or pull request

Comments

@veripoolbot
Copy link
Contributor


Author Name: Pieter Kapsenberg
Original Redmine Issue: 1603 from https://www.veripool.org


This syntax is not allowed by verilator:

module test;
parameter DEMO = 1;
always begin: DEMO
  $finish;
end
endmodule

Results in the following error.
%Error: test.sv:3: Unsupported in C: Block has the same name as variable: DEMO
%Error: test.sv:2: ... Location of original declaration

What exactly is the limitation here? C99 at least does allow this:

#include "stdio.h"

int main() {
  int x = 0;
x:
  printf("x is %d\n", x);
  return 0;

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Pieter Kapsenberg
Original Date: 2019-11-15T02:11:57Z


Ok well that formatting failed - trying again:

This syntax is not allowed by verilator:

module test;
parameter DEMO = 1;
always begin: DEMO 
  $finish;
end
endmodule

</code>

Results in the following error:

%Error: test.sv:3: Unsupported in C: Block has the same name as variable: DEMO
%Error: test.sv:2: ... Location of original declaration

</code>

What exactly is the limitation here? C99 at least does allow this:

#include "stdio.h"

int main() {
  int x = 0;
x:
  printf("x is %d\n", x);
  return 0;
}

</code>

@veripoolbot
Copy link
Contributor Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-15T09:08:38Z


This is to protect against what in some cases may become:

int foo;
void foo();

which causes a mess of course. Verilator does currently rename some constructs by adding PVT to the names, but this same prefix would be added to both, so there would still be a conflict. Perhaps a different prefix could be used for variables and blocks, but this sort of name collision seems a bad practice, and certainly would be a lint problem regardless, so I'm reluctant to add code and break backward compatibility for it.

@veripoolbot veripoolbot added the resolution: wontfix Closed; work won't continue on an issue or pull request label Dec 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: wontfix Closed; work won't continue on an issue or pull request
Projects
None yet
Development

No branches or pull requests

1 participant