GCC always assumes aligned pointer accesses
trust-in-soft.com
GCC always assumes aligned pointer accesses
1–10 of 93 posts
Re: GCC always assumes aligned pointer accesses
#2The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory.
I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
Re: GCC always assumes aligned pointer accesses
#3The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
Yes, this is the compiler optimizing UB due to aliasing, not due to alignment.
Re: GCC always assumes aligned pointer accesses
#4The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
Isn’t that in practice the same as an alignment problem? Can you have two ints overlap without a misaligned access?
Re: GCC always assumes aligned pointer accesses
#5The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
-fno-strict-aliasing: https://stackoverflow.com/questions/98650/what-is-the-strict...
Torvalds rant: https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing
edit: I misread the parent as wondering about a compiler flag
Re: GCC always assumes aligned pointer accesses
#6The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
Isn’t that in practice the same as an alignment problem? Can you have two ints overlap without a misaligned access?
[deleted]
Re: GCC always assumes aligned pointer accesses
#7This isn't just an issue with GCC but embedded compilers as well. On embedded systems its common to work with packed data structures to maximize serial protocol efficiency.
Lets say you have a packed structure with a type of
struct MyPackedStruct {
uint8_t byteValue;
uint32_t intValues[5];
}
But if you do something like this:
uint32_t *intValues = myPacktedStruct.intValues;
Moral of the story - only use packed data types when serializing/deserializing a protocol stream. Avoid using packed data types 'at rest', because it can cause subtle issues like this. The downside is that it results in extra parsing work when converting between packed and unpacked types.
Re: GCC always assumes aligned pointer accesses
#8No. [as in: this isn't about GCC.]
The C standard requires that pointers generally be created from referencing a valid, existing object. A misaligned integer is not a valid "object", thus the compiler may assume that all pointers to ints are aligned (to 4 bytes.)
https://en.cppreference.com/w/cpp/language/pointer
Every value of pointer type is one of the following:
- a pointer to an object or function (in which case the pointer is said to point to the object or function), or
- a pointer past the end of an object, or
- the null pointer value for that type, or
- an invalid pointer value.
Edit/Add: that's C++ in the link above, but it's the same in C. You can get a pointer from either a valid static/stack object, or malloc, which is "max" aligned. Either way it's required to point to a valid object, which includes correct alignment. If you implement your own memory management / allocator, it's also your responsibility to meet these same alignment requirements.
Re: GCC always assumes aligned pointer accesses
#9The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
-fno-strict-aliasing: https://stackoverflow.com/questions/98650/what-is-the-strict... Torvalds rant: https://www.yodaiken.com/2018/06/07/torvalds-on-aliasing edit: I misread the parent as wondering about a compiler flag
Irrelevant to the post, even without strict aliasing the compiler will assume pointers/objects are properly aligned.
Re: GCC always assumes aligned pointer accesses
#10The complaint isn't about alignment at all, it's that the optimizer assumes that two pointers to the same basic type cannot overlap in memory. The generated code is correct except for the fact that the two arguments are distinct pointers to the same three bytes in memory. I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
> I believe this behavior is actually specified in the standard, actually, in the same section that defines the aliasing rules.
It is, indirectly, since pointers are required to point to valid objects, and valid objects are required to be correctly aligned.