Dear all,
this is a proposal to improve the usefulness of clang in the context of systems
programming and embedded systems.
Our goal is to complete the code generation support of the existing __unaligned
support, which is implemented in clang as a Microsoft extension[1] under
-fms-extensions.
We have implemented most of the proposal but we'd want to gather feedback from
the community so we can contribute an implementation that successfully fits the
existing project goals.
1. Context
It’s actually not too hard; the way to do it is with a typedef:
typedef int attribute((aligned(1))) ui;
ui *P;
OK.
I don’t really see the need for a flag to control this. What unexpected changes to the generated code are you concerned about?
I don’t think we want __unaligned to affect record layout, we just want it to affect the alignment used when loading and storing an unaligned type. That’s the way I read the MSDN description of __unaligned. I don’t think Clang should implement its own, different semantics from MSVC for __unaligned. That causes confusion and the compatibility issues you mention.
I think programmers already have enough tools to control record layout. They have attribute((packed)) and attribute((aligned(N))). What they don’t have are good tools to take unaligned pointers from code they don’t control and access them safely. The MSVC version of __unaligned lets you do that, so I think we should just finish implementing it as described and call it a day.
Hi all,
thanks for the feedback.
Richard: On a second thought, it looks like it may not have much impact in the code generation, at least in x86. This was just in case unaligned accesses start to appear in other targets. But maybe I’m being too cautious here. So I will drop the flag from the patch.
Reid: I agree that there is enough machinery now for packed fields and __unaligned would add little here. I will be dropping this from the patch as well.
Kind regards,
Roger