[Bug target/111849] New: GCC replaces volatile struct assignments with memcpy calls

[Bug target/111849] New: GCC replaces volatile struct assignments with memcpy calls

[bugdal at aerifal dot cx]

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

            Bug ID: 111849
           Summary: GCC replaces volatile struct assignments with memcpy
                    calls
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

On at least some targets where GCC compiles struct assignments to memcpy calls,
this pattern is also used when the struct objects involved are
volatile-qualified. This is invalid; the memcpy function has no contract to
work on volatile objects, and making it compatible with volatile objects would
impose extreme implementation constraints that would limit its performance. For
example, memcpy may copy the same byte more than once to avoid branches, may
use special store instructions with particular cache semantics or data transfer
sizes that aren't compatible with various volatile objects like memory-mapped
registers, etc.

I don't think the C standard is very clear on what is supposed to happen for
volatile struct assignments, but they should at least be done in a way that's
known to be compatible with any memory-mapped interfaces supported on the
target architecture, and the safe behavior is probably implementing them as
member-by-member assignment with some fixup for padding.

I found this while looking at ways to suppress generation of external calls to
memcpy when compiling very restrictive TUs that aren't allowed to make any
external calls, and being surprised that "just add volatile" was not one of the
ways.

I'm filing this as target component because I think the transformation is
taking place at the target backend layer on affected targets rather than
earlier, but I'm not certain. This should be reviewed and possibly reclassified
if that's wrong.

[Bug middle-end/111849] GCC replaces volatile struct assignments with memcpy calls

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
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.

[Bug middle-end/111849] GCC replaces volatile struct assignments with memcpy calls

[bugdal at aerifal dot cx]

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

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
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.