https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122227
--- Comment #8 from celeriyacon <trufflenose at proton dot me> --- (In reply to Andrew Pinski from comment #6) > There is no bug here. IN the case of -O0, the alignment is based on the type > being accessed which you marked as 4 byte aligned. at -O2, the alignment is > based on what is know about &data[0] which is 1 (which is unaligned) as that > used when expanding from gimple to rtl (from a high level IR to the lower > level IR). > > unaligned volatile stores is a load followed by a store aka &=. > > clang has a similar behavior except it produces the similar code gen at -O0 > and -O2. In that test_write_a is based on the known alignment of &data[0] > while test_write_b is based on __builtin_assume_aligned. test_write_a is > always implemented as `&=0` and always unaligned. > > There is no bug here. If you want aligned load you need to align the > variable. I feel like you just explained what gcc does, and because gcc is doing what gcc does, therefore the bug is invalid, without even touching on what part of the standard dictates such...insane...behavior. Are you implying that gcc can unpredictably transform any access to volatile memory of unknown alignment into multiple byte accesses, while also including spurious reads for stores? Because if so, that would make gcc nearly worthless for embedded development. If the presence of spurious reads is correct, should the correct behavior really rely on enabling optimizations? Are both behaviors "correct"? I thought most of the point of volatile was to not have this ridiculous ambiguity in how the compiler will transform the access. You've also misrepresented how clang treats it; clang does NOT emit spurious loads for my example code.
