[cpullvm] Specify and require -munaligned-access for Arm/AArch64 variants that currently build with unaligned access (#389)#447
Open
Jonathon Penix (jonathonpenix) wants to merge 1 commit into
Conversation
…ants that currently build with unaligned access (qualcomm#389) Requiring `-munaligned-access` for multilib should provide better build-time safeguards if people try using `-mno-unaligned-access` when they truly need it disabled. If people require an aligned variant, we'll consider adding one in the future. And, if people want to mix and match (build with `-mno-unaligned-access` but match against a library built with `-munaligned-access`) they can still override multilib and point at the library variant manually. At the same time, expicitly specify `-munaligned-access` for these configs in the compile flags. This should be NFC, but will hopefully make it more clear what our intent for these variants is and safeguard us from any unforseen changes in defaults, etc. Note that this also shouldn't impact our musl configs where we specify `-mstrict-align`/`-mno-unaligned-access` via `EXTRA_MUSL-EMBEDDED_CFLAGS`--those are used when building musl *only* and those flags are placed after the generic `COMPILE_FLAGS` so will override them. As mentioned above, this should resolve qualcomm#388 for now until we want to support aligned variants. (Backported from 13fce8b) Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
b8df9c5 to
f2efd96
Compare
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.
Requiring
-munaligned-accessfor multilib should provide better build-time safeguards if people try using-mno-unaligned-accesswhen they truly need it disabled.If people require an aligned variant, we'll consider adding one in the future. And, if people want to mix and match (build with
-mno-unaligned-accessbut match against a library built with-munaligned-access) they can still override multilib and point at the library variant manually.At the same time, expicitly specify
-munaligned-accessfor these configs in the compile flags. This should be NFC, but will hopefully make it more clear what our intent for these variants is and safeguard us from any unforseen changes in defaults, etc.Note that this also shouldn't impact our musl configs where we specify
-mstrict-align/-mno-unaligned-accessviaEXTRA_MUSL-EMBEDDED_CFLAGS--those are used when building musl only and those flags are placed after the genericCOMPILE_FLAGSso will override them.As mentioned above, this should resolve #388
for now until we want to support aligned variants.
(Backported from 13fce8b)