Repository navigation
edg: the bit-field knob is refuted; the fix is kencc and needs no reg… - #623
Merged
Merged
Conversation
…eneration Section 2 on the VM answers 4 and 8 for both cases, so kencc's rule is MSVC's and the identification holds. The inference from it does not. A cpfe rebuilt with TARG_MICROSOFT_BIT_FIELD_ALLOCATION 1 does change its own model -- offsetof 4, sizeof 8, and 160 for the real shape, all kencc's numbers -- and the emitted padding does not move: a regenerated mem_manage.c still carries char __dummy[7], character for character. c_gen_be.c:3132's offset_after_field is why, and it is gated on msvc_is_generated_code_target rather than on the target variable. Its non-Microsoft arm gives offset + ceil(bits/8) = 153, so the padding is 160-153 = 7. The front-end layout and what the C back end assumes about the compiler building its output are two different axes, and I treated them as one -- the same mistake this NOTE already records for the __weak__ suppression against the TARG_ widths. The second axis is not available: it gates eighteen sites in c_gen_be.c plus four more files, __cdecl and __declspec among them, and the padding calculation is one of the eighteen. The knob is reverted. With the remaining fix it would be actively wrong, since cpfe would model a rule kencc no longer follows. What is left is kencc's own bit-field allocation, and it needs no regeneration: the committed corpus is already correct for a compiler that shares the container, so one compiler change makes 2.9M lines right as they stand. Run apeabi-probe before deciding, which is the recorded rule for an ABI change of this shape. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…eneration
Section 2 on the VM answers 4 and 8 for both cases, so kencc's rule is MSVC's and the identification holds. The inference from it does not.
A cpfe rebuilt with TARG_MICROSOFT_BIT_FIELD_ALLOCATION 1 does change its own model -- offsetof 4, sizeof 8, and 160 for the real shape, all kencc's numbers -- and the emitted padding does not move: a regenerated mem_manage.c still carries char __dummy[7], character for character.
c_gen_be.c:3132's offset_after_field is why, and it is gated on msvc_is_generated_code_target rather than on the target variable. Its non-Microsoft arm gives offset + ceil(bits/8) = 153, so the padding is 160-153 = 7. The front-end layout and what the C back end assumes about the compiler building its output are two different axes, and I treated them as one -- the same mistake this NOTE already records for the weak suppression against the TARG_ widths.
The second axis is not available: it gates eighteen sites in c_gen_be.c plus four more files, __cdecl and __declspec among them, and the padding calculation is one of the eighteen.
The knob is reverted. With the remaining fix it would be actively wrong, since cpfe would model a rule kencc no longer follows.
What is left is kencc's own bit-field allocation, and it needs no regeneration: the committed corpus is already correct for a compiler that shares the container, so one compiler change makes 2.9M lines right as they stand. Run apeabi-probe before deciding, which is the recorded rule for an ABI change of this shape.
Claude-Session: https://claude.ai/code/session_01WGAwvvTwDg2yknFkmZ3qzs