You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
results in this error, when synthesized (with -verilog, say):
Error: "Test.bsv", line 6, column 35: (G0028)
`v' uses uninitialized value (the position shown is the object's
declaration). If this error is unexpected, please consult KPNS #32.
During elaboration of the body of rule `r' at "Test.bsv", line 5, column 8.
During elaboration of `mkTest' at "Test.bsv", line 4, column 8.
I thought there was already an issue filed for this, but I don't see one.
A workaround is to give an initial assignment, but then we lose the ability to track whether any elements are not assigned -- for which we would still like to receive uninit errors. It would help if the Vector package exported a function that returns a Vector with uninitialized elements, and then we could replicate that to make a 2D Vector with uninitialized leaves. (Alternatively, if the Vector package defined and exported primMarkVectorInitialized, then we could call that on v -- as a workaround.)
A possible fix might be to define an instance of primMakeUninitialized for Vector n (Vector m a) that doesn't call markVectorUninitialized on the outer Vector. However, if the user failed to initialize one of the elements of the outer Vector, they would get m errors (for each of the elements of the sub Vector). It would be preferable to report just one error. So I'd like to find a better fix.
I assume that the error is because the assignment to v[i][j] is desugared into primUpdateFn applied to v[i], which therefore has to access v[i] that hasn't been assigned. Maybe we need a version of primUpdateFn that, instead of taking the new value of type t, takes a function t -> t that takes the current value as an argument -- and then we could nest calls to primUpdateFn.
The text was updated successfully, but these errors were encountered:
The following code:
results in this error, when synthesized (with
-verilog
, say):I thought there was already an issue filed for this, but I don't see one.
A workaround is to give an initial assignment, but then we lose the ability to track whether any elements are not assigned -- for which we would still like to receive uninit errors. It would help if the
Vector
package exported a function that returns a Vector with uninitialized elements, and then we couldreplicate
that to make a 2D Vector with uninitialized leaves. (Alternatively, if theVector
package defined and exportedprimMarkVectorInitialized
, then we could call that onv
-- as a workaround.)A possible fix might be to define an instance of
primMakeUninitialized
forVector n (Vector m a)
that doesn't callmarkVectorUninitialized
on the outer Vector. However, if the user failed to initialize one of the elements of the outer Vector, they would getm
errors (for each of the elements of the sub Vector). It would be preferable to report just one error. So I'd like to find a better fix.I assume that the error is because the assignment to
v[i][j]
is desugared intoprimUpdateFn
applied tov[i]
, which therefore has to accessv[i]
that hasn't been assigned. Maybe we need a version ofprimUpdateFn
that, instead of taking the new value of typet
, takes a functiont -> t
that takes the current value as an argument -- and then we could nest calls toprimUpdateFn
.The text was updated successfully, but these errors were encountered: