Skip to content

Discussion : structural invariants on goto-programs #1746

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

Closed
martin-cs opened this issue Jan 17, 2018 · 5 comments
Closed

Discussion : structural invariants on goto-programs #1746

martin-cs opened this issue Jan 17, 2018 · 5 comments

Comments

@martin-cs
Copy link
Collaborator

At which points in the system, if any, is it acceptable to have a GOTO instruction whose target is the next instruction? For example:

if CONDITION goto next;
next : ...

I ask because remove_skip recognises (and removes) this case and many of the older abstract domains are written (implicitly) assuming it does not occur. So can/should we always assume that remove_skip has been run after any program transformations / input? Or should I update the domains so they are correct for this kind of program?

@peterschrammel
Copy link
Member

domains are written (implicitly) assuming it does not occur

What is the performance optimisation enabled by this assumption?

@martin-cs
Copy link
Collaborator Author

@peterschrammel
Copy link
Member

peterschrammel commented Jan 17, 2018

Why wouldn't it take a join at the GOTO target location (next)?

@peterschrammel
Copy link
Member

The current implementation is simply unsound. Assumptions on the absence of certain control flow patterns are not a good idea and should be fixed.

@martin-cs
Copy link
Collaborator Author

OK, will fix all instances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants