Skip to content

fix alignment computation for nested objects #57722

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
Mar 11, 2025

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Mar 11, 2025

The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding).

Addresses #57713 (comment)

@vtjnash vtjnash added the backport 1.12 Change should be backported to release-1.12 label Mar 11, 2025
@vtjnash vtjnash requested a review from gbaraldi March 11, 2025 14:51
@KristofferC KristofferC added backport 1.10 Change should be backported to the 1.10 release backport 1.11 Change should be backported to release-1.11 labels Mar 11, 2025
@vchuravy

This comment was marked as outdated.

The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset. This
can be strongly counter-intuitive (as it implies adding padding where it
does not seem to provide value), but is required to match the C standard.
It also permits users to write custom allocators which happen to provide
alignment in excess of that which codegen may assume is guaranteed, and
get the behavioral characteristics they intended to specify (without
resorting to computing explicit padding).

Addresses #57713 (comment)
@vtjnash vtjnash force-pushed the jn/struct-align-mistake branch from e449fb1 to d6271e5 Compare March 11, 2025 15:25
@vtjnash vtjnash added the merge me PR is reviewed. Merge when all tests are passing label Mar 11, 2025
@KristofferC KristofferC merged commit c9008ff into master Mar 11, 2025
7 of 8 checks passed
@KristofferC KristofferC deleted the jn/struct-align-mistake branch March 11, 2025 19:42
vtjnash added a commit that referenced this pull request Mar 12, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(Cherry-picked from c9008ff, with
typo fix to typed_loaded memcpy which was already deleted from master)
vtjnash added a commit that referenced this pull request Mar 12, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(Cherry-picked from ec3c02a in
v1.11 backports branch)
@giordano giordano removed the merge me PR is reviewed. Merge when all tests are passing label Mar 14, 2025
KristofferC pushed a commit that referenced this pull request Mar 20, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(cherry picked from commit c9008ff)
@KristofferC KristofferC removed the backport 1.12 Change should be backported to release-1.12 label Mar 24, 2025
KristofferC pushed a commit that referenced this pull request Mar 25, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(Cherry-picked from c9008ff, with
typo fix to typed_loaded memcpy which was already deleted from master)
@KristofferC KristofferC mentioned this pull request Mar 31, 2025
71 tasks
KristofferC pushed a commit that referenced this pull request Mar 31, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(Cherry-picked from ec3c02a in
v1.11 backports branch)
KristofferC pushed a commit that referenced this pull request Mar 31, 2025
The alignment of a nested object (in C layouts) is not affected by the
alignment of its parent container when computing a field offset (as if
it will be allocated at address 0). This can be strongly
counter-intuitive (as it implies it should add padding where it does not
seem to provide value to the user), but this is required to match the C
standard. It also permits users to write custom allocators which happen
to provide alignment in excess of that which codegen may assume is
guaranteed, and get the behavioral characteristics they intended to
specify (without resorting to computing explicit padding).

Addresses
#57713 (comment)

(Cherry-picked from ec3c02a in
v1.11 backports branch)
@KristofferC KristofferC removed the backport 1.11 Change should be backported to release-1.11 label Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport 1.10 Change should be backported to the 1.10 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants