GCC always assumes aligned pointer accesses (2020)
trust-in-soft.com
GCC always assumes aligned pointer accesses (2020)
1–10 of 128 posts
Re: GCC always assumes aligned pointer accesses (2020)
#2The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags.
When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything".
Trying to scope that down using arguments of the form "but what the hardware does is X" are fundamentally flawed, because anything means anything, and what the hardware does doesn't change that, and therefore it doesn't matter.
This blogpost "What The Hardware Does is not What Your Program Does" explains this in more detail and with more examples.
Re: GCC always assumes aligned pointer accesses (2020)
#3We need an '__unaligned' modifier for pointers to specify that the pointer will be used for unaligned reads and writes.
Re: GCC always assumes aligned pointer accesses (2020)
#4The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
This line in particular really bugs me:
> The present blog post brings bad, and as far as I know, previously undocumented news. Even if you really are targeting an instruction set without any memory access instruction that requires alignment, GCC still applies some sophisticated optimizations that assume aligned pointers.
I could have told you this was true ~20 years ago, and the main reason I'm so conservative in how far back gcc has been doing this is that it's only around that time I started programming--I strongly suspect this dates back to the 90's.
Re: GCC always assumes aligned pointer accesses (2020)
#5We need an '__unaligned' modifier for pointers to specify that the pointer will be used for unaligned reads and writes.
Why not just use memcpy()?
Re: GCC always assumes aligned pointer accesses (2020)
#6Re: GCC always assumes aligned pointer accesses (2020)
#7We need an '__unaligned' modifier for pointers to specify that the pointer will be used for unaligned reads and writes.
If you've got control over the type of the pointee and not just the pointer, __attribute__((packed)) can work for this.
struct foo { int x; };
struct bar { __attribute__((packed)) int x; };
_Static_assert(_Alignof(struct foo) == 4, "");
_Static_assert(_Alignof(struct bar) == 1, "");Re: GCC always assumes aligned pointer accesses (2020)
#8The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
This line in particular really bugs me: > The present blog post brings bad, and as far as I know, previously undocumented news. Even if you really are targeting an instruction set without any memory access instruction that requires alignment, GCC still applies some sophisticated optimizations that assume aligned pointers. I could have told you this was true ~20 years ago, and the main reason I'm so conservative in ho…
It dates to the first standardization of C in 1989. The "C as portable assembly" view ended when ANSI C got standardized, and K&R's 2nd edition was published.
Re: GCC always assumes aligned pointer accesses (2020)
#9The arguments in this blogpost are fundamentally flawed. The fact that they opened a bug based on them but got shut down should have raised all red flags. When compiling and running a C program, the only thing that matters is "what the C abstract machine does". Programs that exhibit UB in the abstract machine are allowed to do "anything". Trying to scope that down using arguments of the form "but what the hardware do…
This line in particular really bugs me: > The present blog post brings bad, and as far as I know, previously undocumented news. Even if you really are targeting an instruction set without any memory access instruction that requires alignment, GCC still applies some sophisticated optimizations that assume aligned pointers. I could have told you this was true ~20 years ago, and the main reason I'm so conservative in ho…
indeed, I still have ~20 years old code that picks up and rectifies unaligned memory so gcc does the right thing. To claim a compiler bugs out on unaligned memory sounds very weird, I assumed that was common knowledge.
Re: GCC always assumes aligned pointer accesses (2020)
#10We need an '__unaligned' modifier for pointers to specify that the pointer will be used for unaligned reads and writes.
If you've got control over the type of the pointee and not just the pointer, __attribute__((packed)) can work for this. struct foo { int x; }; struct bar { __attribute__((packed)) int x; }; _Static_assert(_Alignof(struct foo) == 4, ""); _Static_assert(_Alignof(struct bar) == 1, "");
Yeah, I end up using __attribute__((packed)) for this at work. For tortured reasons, part of our codebase allocates memory with only 8-byte alignment, but the buffer is cast to a type that would have 16-byte alignment without __attribute__((packed)). As a result Clang wants to generate VMOVDQAs that require 16-byte alignment, unless you use packed, in which case it generates VMOVDQU.