-
Notifications
You must be signed in to change notification settings - Fork 425
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
Pad bit-fields only to the next byte #1058
Conversation
Fixes cc65#1054. Previously, bit-fields followed by another field were aligned to two bytes. Bit-fields ending the struct were (and continue to be) aligned only to a single byte. ``` struct s { unsigned int x : 4; }; struct t { unsigned int x : 4; unsigned int y; }; ``` Before: `sizeof(struct s) == 1`, sizeof(struct t) == 4` After: `sizeof(struct s) == 1` sizeof(struct t) == 3`
I'll also try to add some tests. |
Bit-field initializers still are stored as two bytes. Do you want to fix that in this PR, or in a separate PR? |
I'll fix it here. Could you merge #1059 so I can send a follow-up that gets the |
The tests I added in #1063 cause CHECK failures. I'll let you know when I have a new version with that fixed. |
This prepares for cc65#1058, which will pad bit-fields only to the next byte, instead of the next sizeof(int) (two bytes). OutputBitFieldData now outputs chars instead of ints, and calls to this function loop until there is less than one byte to output. A final partial byte is written out with zero padding as a final partial int was previously.
This is in #1066 instead of this PR. |
This prepares for #1058, which will pad bit-fields only to the next byte, instead of the next sizeof(int) (two bytes). OutputBitFieldData now outputs chars instead of ints, and calls to this function loop until there is less than one byte to output. A final partial byte is written out with zero padding as a final partial int was previously.
Sorry, I'm a bit lost here. I understand the statement above as #1066 fixing something regarding this PR (#1058). But #1066 is already merged while this PR (#1058) is not. @jmr @greg-king5: Can you please shed some light on the status of this PR? |
#1066 was fixing something related to this PR, but it was also safe to do before this one, so I did it separately.
This is ready to be merged, but it would be better to merge #1063 first so there's more test coverage. This PR changes some sizes that are checked in #1063 , so I need to change something before the second one is merged. |
No. Either can be merged first, then the other will need to be updated. |
Now that #1071 is sorted out we can move forward again. |
MSVC complains about unary negation of unsigned, but it's intended. Suppress the warning. cc65#1058 (comment) "Tested" with godbolt.org.
MSVC complains about unary negation of unsigned, but it's intended. Suppress the warning. #1058 (comment) "Tested" with godbolt.org.
Fixes #1054.
Previously, a bit-field followed by a non-bit field was expanded to two bytes. A bit-field ending the struct was (and continues to be) expanded to only a single byte.
Before:
sizeof (struct s) == 1
,sizeof (struct t) == 4
After:
sizeof (struct s) == 1
,sizeof (struct t) == 3