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
Linting error: backward indexing #1507
Comments
Original Redmine Comment Thanks for the report, simple enough to fix. Fixed in git towards 4.420. |
Original Redmine Comment Wilson Snyder wrote:
Thanks for the quick fix. May I know when I can start to use the new version? |
Original Redmine Comment You can get it now from git, see the Install section. Typically releases (tarballs) are every month or so. |
Original Redmine Comment Wilson Snyder wrote:
Can you please see if my command has some issues? I used:
Then "git tag" shows the latest version is verilator_4_018 or v4.018. Not quite sure if I missed anything. Thanks, |
Original Redmine Comment It's not released (until next monthish), use master branch, that is don't use any tag. |
Original Redmine Comment Let me know if it is better to open a new issue, since it is unrelated topic. I am on the master branch right now, but I don't see the updates. Please see my command history: hao@haos:~/Downloads/test/verilator$ git branch
stable hao@haos:~/Downloads/test/verilator$ git pull Already up-to-date. hao@haos:~/Downloads/test/verilator$ git log commit 3469c78
commit baa6343
|
Original Redmine Comment Sorry, not having it in master was my fault, try again. |
Original Redmine Comment It worked fine. Thanks! |
Original Redmine Comment In 4.020. Thanks for reporting this; if there are additional related problems, please open a new issue. |
Author Name: Hao Shi
Original Redmine Issue: 1507 from https://www.veripool.org
Original Assignee: Wilson Snyder (@wsnyder)
I think I met a false error in linting:
Slice selection '[2:2]' has backward indexing versus data type's '[0:3]'
Slice selection '[3:3]' has backward indexing versus data type's '[0:3]'
If the data type is declared as [3:0], then it won't complain. Therefore, it looks like that the tool treats [i:i] as big-to-small. However, it can still be treated as small-to-big.
Thanks,
Hao
The text was updated successfully, but these errors were encountered: