[Bug middle-end/111849] GCC replaces volatile struct assignments with memcpy calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849 --- Comment #2 from Rich Felker --- I agree that volatile isn't the best way to handle memcpy suppression for other purposes - it was just one of the methods I experimented with that led to me discovering this issue, which I found surprising and reported. With regards to impact of this bug, in discussion within the musl libc community where it was found, I did encounter one potentially affected user who is using volatile struct stores to write entire bitfields at once on mmio registers instead of (possibly invalid, at least inefficient) read-modify-write cycles on each bitfield member. I believe their use was unaffected, probably because the whole struct is small enouth that it gets emitted as direct load/store rather than a memcpy call.
[Bug middle-end/111849] GCC replaces volatile struct assignments with memcpy calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111849 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Richard Biener --- Note that whoever uses a struct assignment to write to memory mapped interfaces is going to rely on vastly differing behavior of compilers. So I expect this to occur in almost zero cases out in the wild (not to mention the handling of padding). As to volatile structs or structs with volatile members, any special-handling needs to be ensured by the language frontends here. To avoid memcpy generation Alex posted some patches for this, volatile is not the best way to ensure this.
