It seems that there are two ways of calling the external function, one
with it having type StgFunPtr and coercing it before use, and one with
assuming it to have the type it has. If both are used in the same file,
things break. Maybe the first style comes from a standard FFI call, and
the second style somehow from “more internal” code, as it works with
MUT_ARR_PTRS? {{{doCopyMutableByteArrayOp}}} or a related function in
source:compiler/codeGen/StgCmmPrim.hs is a hot candidate, as they call
{{{emitMemcpyCall}}}.

But if I then modify the .hc file and move the {{{memcpy((void *)_c19o,
(void *)_c19n, _c19m);}}} call to the bottom of the file, after the
{{{EF_(memcpy)}}}, then I get:
{{{
/tmp/ghc13380_0/ghc13380_0.hc: In function ‘Test_zdwccall_entry’:
/tmp/ghc13380_0/ghc13380_0.hc:43:2: warning: conflicting types for built-
in function ‘memcpy’ [enabled by default]
/tmp/ghc13380_0/ghc13380_0.hc: In function ‘Test_test_entry’:
/tmp/ghc13380_0/ghc13380_0.hc:181:1: warning: implicit declaration of
function ‘memcpy’ [-Wimplicit-function-declaration]
/tmp/ghc13380_0/ghc13380_0.hc:74:2: note: previous declaration of ‘memcpy’
was here
/tmp/ghc13380_0/ghc13380_0.hc:181:1: error: incompatible implicit
declaration of function ‘memcpy’
/tmp/ghc13380_0/ghc13380_0.hc:74:2: note: previous implicit declaration of
‘memcpy’ was here
}}}
so the order of declarations gets important.

So a solution seems to be to generate the {{{EF_(...)}}} style call also
for memcpy (is there a runtime performance penalty)? The code to look at
seems to be source:compiler/cmm/PprC.hs, especially {{{pprStmt}}}, where a
memcpy can occur as a {{{CmmPrim MO_Memcpy}}} or as a {{{CmmCall}}} (which
does the EF_ stuff).

This does prevent `Foreign.coypBytes` from using the builtin `memcpy` in
the C backend, for example. Also it's another gcc dependency. Do we need
to worry about which gcc versions support `-fno-builtin-memcpy`?

I think I thought that we could just get the C types right. But actually
I don't care that much and I don't think it's worth spending a lot of time
on - so go ahead and push as long as there's no issue with old gcc
versions.