-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
alignment: subtly change meaning of datatype_align #34473
Conversation
add26de
to
cab4372
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
cab4372
to
5fbbb4d
Compare
Let's rebase this and try to get a better CI run. |
5fbbb4d
to
b308f8c
Compare
test/vecelement.jl
Outdated
v = ntuple(w -> Float64(10w), Val(8)) | ||
return a, (v, (a, (1e6, 1e9))) | ||
end | ||
@test bar32414(-35.0) === (-35.0, ((10.0, 20.0, 30.0, 40.0, 50.0, 60.0, 70.0, 80.0), (-35.0, (1.0e6, 1.0e9)))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unlike the example in #32414 this test passes for me on master. Should we add a version that includes VecElement
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I just pasted the wrong one here
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes #32414
b308f8c
to
407fecb
Compare
Doesn't backport cleanly. Can push a backport to #34517. |
Bump for backport. |
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes #32414
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes #32414 (cherry picked from commit 268ac24)
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes #32414
Rather than meaning the actual alignment of the object, this now means the preferred alignment of the object. The actual alignment of any object is the minimum of this preferred alignment and the alignment supported by the runtime allocator. This aligns us with how LLVM treats alignment, and is probably reasonably sensible anyways. Also tries to audit our existing uses of CreateLoad/CreateStore for correctness, and upgrade some to include pointer-types. fixes JuliaLang#32414 (cherry picked from commit 268ac24)
Rather than meaning the actual alignment of the object, this now means
the preferred alignment of the object. The actual alignment of any
object is the minimum of this preferred alignment and the alignment
supported by the runtime allocator. This aligns us with how LLVM treats
alignment, and is probably reasonably sensible anyways.
Also tries to audit our existing uses of CreateLoad/CreateStore for
correctness, and upgrade some to include pointer-types.
fixes #32414