Skip to content
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

Synchronise goto-cc command-line options to re-enable Windows regression tests #5572

Closed

Conversation

tautschnig
Copy link
Collaborator

object-bits was not supported by all of goto-cc's command-line front-end
variants. While at it, also make other options consistently available.

  • 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 Nov 12, 2020

Codecov Report

Merging #5572 (774abc1) into develop (16ed35a) will not change coverage.
The diff coverage is 0.00%.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #5572   +/-   ##
========================================
  Coverage    69.31%   69.31%           
========================================
  Files         1241     1241           
  Lines       100407   100407           
========================================
  Hits         69596    69596           
  Misses       30811    30811           
Flag Coverage Δ
cproversmt2 43.07% <ø> (ø)
regression 66.21% <0.00%> (ø)
unit 32.27% <ø> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/goto-cc/armcc_cmdline.cpp 26.92% <ø> (ø)
src/goto-cc/bcc_cmdline.cpp 0.00% <ø> (ø)
src/goto-cc/ms_cl_cmdline.cpp 0.00% <0.00%> (ø)
src/goto-cc/ms_link_cmdline.cpp 0.00% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 16ed35a...774abc1. Read the comment docs.

@tautschnig tautschnig force-pushed the fix-goto-cc-object-bits branch 2 times, most recently from 8c7a3c2 to ea9b7c0 Compare November 13, 2020 02:08
…ion tests

object-bits was not supported by all of goto-cc's command-line front-end
variants. While at it, also make other options consistently available.
Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite understand/remember why object-bits is required at all here. It should only have an influence on symbolic execution, but not appear in a goto-program. Going forward this should probably be cleaned up.

@kroening
Copy link
Member

Agreed, goto-cc (or goto-gcc or goto-cl) should not have analysis options.

@tautschnig
Copy link
Collaborator Author

@peterschrammel said:

I don't quite understand/remember why object-bits is required at all here. It should only have an influence on symbolic execution, but not appear in a goto-program. Going forward this should probably be cleaned up.

@kroening said:

Agreed, goto-cc (or goto-gcc or goto-cl) should not have analysis options.

As of 531b856 (#5210) the C front-end needs to determine the value of __CPROVER_max_malloc_size based on this configuration information. Would be unnecessary with #1086, but that's also quite far off.

@kroening
Copy link
Member

__CPROVER_max_malloc_size can just as well be set by the analyser.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, yes, but like others I have concerns about --object-bits.

@tautschnig
Copy link
Collaborator Author

tautschnig commented Nov 13, 2020

__CPROVER_max_malloc_size can just as well be set by the analyser.

@kroening Any suggestions of what would be the cleanest way to do so? We could certainly generate an assignment in goto_symext::initialize_entry_point_state, but that does feel like a hack.

Edit: another option would be to introduce a function __CPROVER_max_malloc_size() and have goto-symex give special treatment to the function call. That, however, would require some awareness of return-value removal.

@tautschnig
Copy link
Collaborator Author

Closing in favour of #7858.

@tautschnig tautschnig closed this Aug 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants