Repository navigation
Fix integer-pointer cast extension to match GCC semantics - #9231
tautschnig wants to merge 1 commit into
Conversation
The SAT and SMT2 back ends disagreed on how to extend integer-to-pointer and pointer-to-integer casts when the types have different widths: - SAT: zero-extended in both directions - SMT2: sign-extended in both directions GCC documents that integer-to-pointer conversion extends according to the signedness of the source integer type, and pointer-to-integer conversion sign-extends. Neither back end matched GCC on all cases. Fix SAT back end (bv_pointers.cpp): - Integer to pointer: sign-extend for signed sources, zero-extend for unsigned sources (was: always zero-extend). - Pointer to integer: sign-extend (was: zero-extend). Fix SMT2 back end (smt2_conv.cpp): - Integer to pointer: extend according to source signedness (was: always sign-extend). - Pointer to integer: already correct (sign-extend), no change. Fixes diffblue#9212 Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #9231 +/- ##
===========================================
- Coverage 80.91% 80.90% -0.01%
===========================================
Files 1718 1718
Lines 190266 190272 +6
Branches 73 73
===========================================
- Hits 153952 153941 -11
- Misses 36314 36331 +17 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This semantics feels extremely compiler and target-specific. The C-frontend should lower the cast to the specific target semantics based on compiler and architecture setting. |
The extract upper index for narrowing an integer to a pointer used to_width instead of to_width-1, producing a bit-vector of to_width+1 bits rather than to_width bits. This caused solver sort errors whenever the source integer was wider than the pointer type, e.g. long long to pointer on --32, or __int128 to pointer on --64. SMT-LIB 2.6 extract semantics: ((_ extract i j) bv) yields bits i downto j inclusive, so the result width is i-j+1. Using to_width as the upper index gave to_width+1 bits; the fix uses to_width-1. This composes with PR diffblue#9231 (which changes the extension direction for narrower-to-wider integer-to-pointer casts but does not touch the narrowing path). Reported by Jeroen Robben (https://reports.robben.io/methodology/). Fixes diffblue#9369 Co-authored-by: Kiro <kiro-agent@users.noreply.github.com>
The SAT and SMT2 back ends disagreed on how to extend integer-to-pointer
and pointer-to-integer casts when the types have different widths:
GCC documents that integer-to-pointer conversion extends according to
the signedness of the source integer type, and pointer-to-integer
conversion sign-extends. Neither back end matched GCC on all cases.
Fix SAT back end (bv_pointers.cpp):
unsigned sources (was: always zero-extend).
Fix SMT2 back end (smt2_conv.cpp):
always sign-extend).
Fixes #9212