An exact answer requires diving into the code transformations that GCC performs and looking at how your code is transformed by GCC. That's beyond what I can do in a reasonable amount of time, but I can show you what's going on in more general terms, without diving into GCC internals.

Here's the crazy part: If you remove inline , you will get memcpy . With inline , you get memmove . I'll show the results on Godbolt and then talk about how compilers work to explain it.

The Code

Here's some test code I put on Godbolt .

__attribute__ ((access(write_only, 1))) __attribute__((nonnull(1, 2)))
extern inline void mymemcpy(void *__restrict__ dest, const void *__restrict__ src, int size)
{
    const unsigned char *s = (const unsigned char*)src;
    unsigned char *d = (unsigned char*)dest;
    while(size--) *d++ = *s++;
}

void test(void *dest, const void *src, int size)
{
    mymemcpy(dest, src, size);
}

Here's the resulting assembly

mymemcpy:
        test    edx, edx
        je      .L1
        mov     edx, edx
        jmp     memcpy
.L1:
        ret
test:
        test    edx, edx
        je      .L4
        mov     edx, edx
        jmp     memmove
.L4:
        ret

Yes, you can see that one function is getting converted to memcpy or memmove . It's not just the same code, it's just one function, which is getting transformed differently depending on whether or not it is inlined. Why?

How Optimization Passes Work

You might think of a C compiler as doing something like this:

1. Preprocess + tokenize source files,
2. Parse to create AST,
3. Type check,
4. Optimize,
5. Emit code.
   In reality, that "optimization" item is many different passes through the code, and each of those passes modify the code in different ways. These passes happen at different times during compilation, and some optimization passes may happen multiple times.
   The order in which specific optimization passes occur affects the results. If you perform optimization X and then optimization Y, you get a different result from doing Y and then X. Maybe one transformation propagates information from one part of the program to another, and then a different transformation acts on that information.
   Why is this relevant here?
   You can see here that there's a restrict pointer src and dest . Since these pointers are restrict , GCC "should" be able to know that memcpy is acceptable, and memmove is not necessary.
   However, that means that the information that src and dest are restrict pointers must be propagated to the loop which is ultimately transformed into memmove or memcpy , and that information must be propagated before the transformation takes place. You could easily first transform the loop into memmove and then, later, figure out that the arguments are restrict , but it's too late!
   It looks like, somehow, the information that src and dest are restrict is getting lost when the function is inlined. This gives us a couple different theories for why this might happen:

• Maybe the propagation of restrict is somehow broken after inlining, due to a bug.
• Maybe GCC infers restrict from the calling function after inlining, under the assumption that the calling function has more context than the function being inlined.
• Maybe the optimization passes don't happen in the right order here for the restrict to propagate to the loop. Maybe that information propagates, and then inlining is performed afterwards, and then the loop optimization happens after that.

Optimization passes (code transformation passes) are sensitive to reordering, after all. This is an extremely complicated area of compiler design.

Disabling The Optimization

Use -fno-tree-loop-distribute-patterns , or use a pragma:

#pragma GCC optimize ("no-tree-loop-distribute-patterns")

简单使用-fno-builtin命令行选项。
https://godbolt.org/z/3Ys1s9jPr