-
Notifications
You must be signed in to change notification settings - Fork 6
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
Label defs and env should not be tied to the main env #77
Comments
Seems to be an issue with |
After taking a look, the problem is the interfering override of This issue really stems from our combining of all environment namespaces into one inherited attribute, and the resulting flow constraints. The forward really doesn't depend on the label environment, only on the misc namespace in this case. You could think of other cases where we would want to only depend on the value namespace, or something else; we essentially would like to be able to access one environment namespace without demanding all the other namespaces be available. Fortunately, the major namespaces for values, tags, and refIds seem to be somewhat interconnected and either will be all present or all absent in most situations. Extension-added namespaces are also somewhat constrained to be the same anyway, since these are really only useful in determining a forward, or other analyses that depend on the forward. IDK about the misc namespace - maybe this is OK I guess? So the solution for this seems to be to split off labels into their own environment attributes - labels are kinda special anyway, since they are visible at locations before their declaration, which is the only reason why we need @tedinski any thoughts on this? |
I can reproduce this same error on extensions that don't override
|
Looks like that second example was related to the labelStmt being within a stmtExpr, and functiondefs doesn't occur on Expr. This means we can't do something like the example below, which gcc accepts, but is kind of pointless because gcc doesn't allow a goto to it. But this is different than what the Cilk extension is trying to do.
|
Yeah, the fix for this (a bit contrived) case would be to make |
I haven't looked closely at this, but do labels inside stmt-exprs really propogate up to the top-level function? I have no idea what jumping to one would mean! |
It appears GCC raises an error with a direct goto into a statement-expression, but they certainly do propagate, as I can do a computed goto!
Anyway, this is a lower-priority problem, for which I will open a seperate issue. The real blocking issue here is the circular dependency with the env as described above. |
I am currently working on fixing this in the feature/env branch, amongst some other random env refactoring. |
I get the following error when attempting to forward to a labelStmt.
error: INTERNAL compiler error: expected to find label in function scope, was missing.
The remaining use of txtStmt in the Cilk extension is related to this. Though I've also tried on a simpler extension and found the same error.
https://github.com/melt-umn/ableC-cilk/blob/develop/grammars/edu.umn.cs.melt.exts.ableC.cilk/abstractsyntax/Sync.sv#L103
The text was updated successfully, but these errors were encountered: