Interestingly enough, I've just checked the code from this article (https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on...), linked by the OP's article, and guess what - CLANG generates code that does not crash, although it still uses SSE4.
GCC always assumes aligned pointer accesses
41–50 of 93 posts
Re: GCC always assumes aligned pointer accesses
#42Few seem to know x86 can generate misaligned access exception. Enabling EFLAGS Alignment Check (bit 18) flag causes an exception on any misaligned access, if the kernel has enabled this feature by setting CR0 register Alignment Mask (bit 18).
You do not need to enable anything. SSE instructions require aligned access, and will crash if used with wrong alignment, irrespective of the flag.
Re: GCC always assumes aligned pointer accesses
#43Few seem to know x86 can generate misaligned access exception. Enabling EFLAGS Alignment Check (bit 18) flag causes an exception on any misaligned access, if the kernel has enabled this feature by setting CR0 register Alignment Mask (bit 18).
You do not need to enable anything. SSE instructions require aligned access, and will crash if used with wrong alignment, irrespective of the flag.
I was talking about scalar 16, 32 and 64 bit alignments. You're confusing that with SSE alignment requirements. Besides, SSE has unaligned load & store as well.
Re: GCC always assumes aligned pointer accesses
#44No. [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 C standard requires that pointers generally be created from referencing a valid, existing object.
It is common to reference memory mapped peripherals by casting an integer to a struct pointer. In that case only a human can certify the validity of the object.
Re: GCC always assumes aligned pointer accesses
#45Earlier quoted context omitted.
-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.
Yeah but alignment is a really really stupid thing to enforce on modern hardware. It makes absolutely no sense at all. All you are doing is increasing your cache pressure and limiting memory bandwidth.
Re: GCC always assumes aligned pointer accesses
#46Earlier quoted context omitted.
Do you have an example where the compiler generates bad code that doesn’t involve misaligned aliases? Many programs rely on misaligned access, and features like pragma packed do too. I doubt they’ll be able to break all of that legacy code.
> Many programs rely on misaligned access, and features like pragma packed do too. I doubt they’ll be able to break all of that legacy code. It's already broken. You're just not seeing it on x86. (Not sure how tolerant ARM is.) I work in network software engineering, i.e. PowerPC used to be a common architecture. Those never accepted misaligned pointers (albeit you could of course trap the misalignment exception and…
I think newer aarch64 allows misaligned access to regular memory.
Re: GCC always assumes aligned pointer accesses
#47This 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]; } Normally a compiler would add 3 extra bytes between the uint8_t value and the uint32_t array to keep alignment of the int array…
Or if you're going to use packed structs, pass around a pointer to the full struct instead of to a member.
Re: GCC always assumes aligned pointer accesses
#48Earlier quoted context omitted.
Sort of. He definitely talks about the fact that it is undefined behaviour to create a misaligned pointer: > Strictly speaking, the function f invokes Undefined Behavior when it computes [the misaligned pointer] But he thinks it is still a problem with GCC, in that GCC should not be allowed to take advantage of this particular UB. He explains his view much better in the bug report: > GCC assumes that pointers must be…
The problem with disabling this optimisation is that it will produce garbage code for basically every architecture. Code which does unaligned accesses are noticeably slow compared to aligned accesses -- this is why there are separate instructions and intrinsics for aligned and unaligned addresses on most architectures. That way you don't pay the penalty of unaligned accesses all the time. But if you try to use the al…
Excepting misalignment that causes a variable to straddle a cache line, modern x86 is generally extremely tolerant of misalignment, performance-wise (for GPR-sized operations). Newer x86 is even pretty performant in the face of misaligned vector-sized accesses.
Re: GCC always assumes aligned pointer accesses
#49Earlier quoted context omitted.
That misaligned access is UB and that gcc's particular behaviour is assuming alignment are two related but different things. The article says that both are true, and the title is simply the second, as that is the more impactful fact.
I disagree that the second is more impactful, but that's because I work with oddball architectures where the UB actually crashes the program ;). I'm wondering though, does UBSAN catch this?
If gcc crashed the program, then that would have been the headline. It's more interesting to know the actual behavior a popular compiler exhibits for a given UB, especially if it's a potentially harmful one, than the mere fact that something is a UB (which you can also just see in the standard).
Re: GCC always assumes aligned pointer accesses
#50Earlier quoted context omitted.
Mixed memory order as in, a memory write stores the data in an order like 5, 7, 6, 4 instead of 4, 5, 6, 7?
Basically yeah, but it gets much more complicated. For example, when a write hits memory is actually not the same thing as when it's observable by some particular other processor. There might be particular rules for writes that have dependencies too. Here's some good reading material if you have a spare afternoon. https://www.kernel.org/doc/Documentation/memory-barriers.txt Amusingly, it treats dependency issues as o…
The modern thing is using acquire/release semantics on the variables you actually care about intra-thread ordering on, rather than full barriers, which impose a higher cost.