Added warning for potential cases of unaligned access when option -mno-unaligned-access has been specified.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
80 ms | x64 debian > LLVM.Bindings/Go::go.test |
Event Timeline
Suggest clarifying the commit message to something like:
"Added warning for potential cases of unaligned access when option -mno-unaligned-access has been specified".
Nice testing :)
clang/lib/Driver/ToolChains/Arch/AArch64.cpp | ||
---|---|---|
463–464 | Nit: preserve coding style of the file. Move the bracket to the previous line, preceded by a space. I.e. if (A->getOption().matches(options::OPT_mno_unaligned_access)) { |
Cleaned up code to make it more clang format friendly. Added another test suite in C.
Two quick comments about when this is enabled, and then I'm happy!
clang/lib/Driver/ToolChains/Arch/ARM.cpp | ||
---|---|---|
772–774 | I think we should be enabling this warning everywhere we enable +strict-align between lines 772 and 813, even though in some of those cases an explicit argument has not been provided to the compiler to enable or disable unaligned accesses. This should probably also be the case for aarch64 too! | |
784–787 | I think you want the curly braces here, as the condition on 774 is looking for both -munaligned-access and -mno-unaligned-access, and then line 776 checks which direction the last argument actually went. |
LGTM! Thanks for your hard work on this!
I think you've addressed @pbarrio's comments on this, and I'm not sure when he's back, so wait 48h before landing this, in case there are further comments.
This caused some driver test failures. They have been fixed in https://reviews.llvm.org/rG11c67e5a4e99f51ec66c9781710f81955cfd5e24
Thanks for the patch!
- When committing code, please add "Differential Revision: https://reviews.llvm.org/D116221" as last line to your commit description, to link the commit to the review. See git log for many examples.
- This breaks tests on Windows, see e.g. http://45.33.8.238/win/52066/step_7.txt Please take a look, and revert for now if it takes a while to fix.
Reverted for the moment in rG3aec4b3d348d69e6c1ead7cba54677b855293983 while we fix the windows tests.
This is coming together well.
I think structs U23 to U26 in the C test are duplicates - how about surrounding them all in #pragma pack(push, 2) so they're different from the earlier cases?
Quite a few more comments inline on the tests.
clang/include/clang/Basic/DiagnosticASTKinds.td | ||
---|---|---|
596–597 | I think the warning text here is misleading, as we are not inspecting the alignment of the parent, we're inspecting the original alignment of the field's struct type vs the resulting alignment of the field. How about this wording, with %2 standing for the field type's name, which you will have to give to the Diag() formatter. Unfortunately, this will mean the wording of the expectations in the tests need to be updated. | |
clang/lib/Driver/ToolChains/Arch/AArch64.cpp | ||
468 | Please guard all the CmdArgs.push_back(…) with if (!ForAS) please - otherwise you get the assembler warnings that I had to fix last time (the same goes for these in ARM.cpp) | |
clang/test/Sema/test-wunaligned-access.c | ||
167 ↗ | (On Diff #399271) | isn't this the same case as struct U1 in this file? |
173 ↗ | (On Diff #399271) | this looks like the same case as struct U5. |
179 ↗ | (On Diff #399271) | This looks the same as struct U8 |
188 ↗ | (On Diff #399271) | this looks the same as struct U16. |
299 ↗ | (On Diff #399271) | This had me scratching my head a bit. Did you expect this to apply to the field itself? Looking at the AST, it doesn't: https://godbolt.org/z/c47KorT3G (note no MaxAlign attribute on the struct) |
322–341 ↗ | (On Diff #399271) | These struct definitions are unused. |
LGTM. I've looked a lot closer at the tests this time around, and am happy with them, and I think the message is phrased better, and there shouldn't be warnings with -cc1as.
clang/lib/Driver/ToolChains/Arch/AArch64.cpp | ||
---|---|---|
221–223 | Sorry if it has been discussed, why the compiler option is not added during constructing the clang job but here? All kinds of clients could call this method, only clang care about this option. |
I think the warning text here is misleading, as we are not inspecting the alignment of the parent, we're inspecting the original alignment of the field's struct type vs the resulting alignment of the field.
How about this wording, with %2 standing for the field type's name, which you will have to give to the Diag() formatter.
Unfortunately, this will mean the wording of the expectations in the tests need to be updated.