On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: > > The C11 standard could indeed use consistent wording. In one place > "correctly aligned" in other alignment "restrictions" and > "requirements". None of these terms is marked as a keyword or term and I > read them in the context of the document as the same phenomenon (I > haven't found a different interpretation of this in the wild).
Right, but, architecturally, x86 doesn't have these "restrictions" or "requirements". Not for correctness, not with the overwhelming majority of integer instructions. Only (sometimes) for performance. Which makes relying on the standard's language about unaligned access incorrect. There's no undefined behavior here because there can't be; strict alignment is not a feature of the target architecture. That means that a compiler which emits broken code if it encounters such a pointer is the broken thing -- *not the source code* -- and whanging around x86 MD code in our tree to accomodate such a compiler would be broken too. I understand we have some code that's on the borderline between being MI and MD, or that's "MD but for several different architectures". ACPICA is an obvious example. And that such code may legitimately be compiled for targets where unaligned access is not architecturally valid, and compilers are free to do odd things with code that tries to do it. But the right thing to do, I think, is to acknowledge that such code is MI; not to, by misguided policy, insist that _all_ "MD" code should be written as if it were MI. Because if you head down that road, we're going to be forced to write a bunch more stuff in assembler that we'd figured out over the decades how to write in a performant and readable way in C; and I don't think anyone benefits from having more asm in our kernel. Thor
