[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Yes, but that is not the fault of the strict volatile code path any more.

For bit-fields this redundant read is exactly what AAPCS demands:

"7.1.7.5 Volatile bit - fields preserving number and width of container
accesses

When a volatile bit-field is read, its container must be read exactly
once using the access width appropriate to the type of the container.

When a volatile bit-field is written, its container must be read exactly
once and written exactly once using the access width appropriate to the
type of the container. The two accesses are not atomic."


IMO, the problem is this:

In store_fixed_bit_field_1 we do not know if the access is on a
packed structure member where the extra read is not necessary,
or if we have a bit-field where the extra read would be mandatory,
even if the complete container is overwritten.


BTW: What happens in your example if you use -O0? Isn't there still an
unaligned stw access?  That's because you example is in a way invalid C.
You can't set an int* to an unaligned address, it must be at least
aligned to the GET_MODE_ALIGNMENT(SImode).