Skip to content

GOTO trace: no timestamps for single-threaded programs #7403

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

Merged
merged 1 commit into from
Jan 12, 2023

Conversation

tautschnig
Copy link
Collaborator

@tautschnig tautschnig commented Dec 1, 2022

Avoid reading clock values when those won't be known to the solver as single-threaded source programs do not have partial-order constraints. Other back-ends were silent about this, but the incremental SMT back-end produced warnings (which the user could do nothing about).

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@codecov
Copy link

codecov bot commented Dec 1, 2022

Codecov Report

Base: 78.39% // Head: 78.40% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (f1a830b) compared to base (b03d870).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #7403   +/-   ##
========================================
  Coverage    78.39%   78.40%           
========================================
  Files         1655     1655           
  Lines       190281   190275    -6     
========================================
+ Hits        149172   149178    +6     
+ Misses       41109    41097   -12     
Impacted Files Coverage Δ
src/goto-symex/build_goto_trace.cpp 87.08% <100.00%> (-0.79%) ⬇️
...ncremental/smt2_incremental_decision_procedure.cpp 96.63% <100.00%> (-0.05%) ⬇️
...ncremental/smt2_incremental_decision_procedure.cpp 98.57% <100.00%> (-0.02%) ⬇️
src/solvers/smt2/smt2_conv.cpp 68.63% <0.00%> (-0.04%) ⬇️
src/util/irep.cpp 99.49% <0.00%> (+1.52%) ⬆️
src/util/irep.h 97.97% <0.00%> (+2.02%) ⬆️
src/util/invariant.cpp 80.39% <0.00%> (+7.84%) ⬆️
src/util/invariant.h 95.55% <0.00%> (+13.33%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@thomasspriggs
Copy link
Contributor

I am happy to see updates to the trace building such that the calls it makes to the decision procedure are more consistent. However it looks like the changes to smt2_incremental_decision_proceduret in this PR will conflict with those in #7404

I haven't done an in-depth review of this PR yet, this is just an initial comment.

@tautschnig
Copy link
Collaborator Author

I am happy to see updates to the trace building such that the calls it makes to the decision procedure are more consistent. However it looks like the changes to smt2_incremental_decision_proceduret in this PR will conflict with those in #7404

I noticed the same when looking at #7404 - I'm more than happy for #7404 to land first, and I'll rebase this one on top of it.

@tautschnig tautschnig force-pushed the cleanup/untimed-trace branch from ed8700e to 4289b5e Compare December 7, 2022 21:51
@tautschnig
Copy link
Collaborator Author

I am happy to see updates to the trace building such that the calls it makes to the decision procedure are more consistent. However it looks like the changes to smt2_incremental_decision_proceduret in this PR will conflict with those in #7404

I noticed the same when looking at #7404 - I'm more than happy for #7404 to land first, and I'll rebase this one on top of it.

Rebased.

Avoid reading clock values when those won't be known to the solver as
single-threaded source programs do not have partial-order constraints.
Other back-ends were silent about this, but the incremental SMT back-end
produced warnings (which the user could do nothing about).
@tautschnig tautschnig force-pushed the cleanup/untimed-trace branch from 4289b5e to f1a830b Compare December 9, 2022 17:02
@peterschrammel peterschrammel removed their assignment Jan 12, 2023
@tautschnig tautschnig merged commit 6a7b97c into diffblue:develop Jan 12, 2023
@tautschnig tautschnig deleted the cleanup/untimed-trace branch January 12, 2023 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants