I'm dealing with issues similar to this bug report: http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888 Let me preface this question with the fact that I understand a conforming hosted C application cannot redefine memcpy. My situtation is that I'm trying to experiment with and improve the C version of memcpy we have in musl libc (http://www.musl-libc.org). This C code is not used on archs where we already have highly-optimized asm, but I want it to be robust against compiler issues so that folks porting to new architectures don't have to fight with memcpy breakage, and I want it to be reasonably efficient, so that you can get by without replacing it with asm until much later. I have always used -ffreestanding, which I believe should make it safe to implement standard library functions without worrying that the compiler will translate them to self-references, but several people on Freenode #gcc claim my interpretation of -ffreestanding is wrong. The issue in the bug report can supposedly be fixed with -fno-tree-loop-distribute-patterns, but my issue is arising when I try to write memcpy using struct assignment with struct block { char data[16]; } the idea of which is to have a large type with no alignment requirement so the compiler can choose how to deal with that (and whether alignment even matters for the arch). On ARM, this is generating calls to memcpy no matter what options I use. However, this got me worrying that there may be other circumstances under which gcc generates calls to memcpy. With all of that said, the real question of this email is: Is there any reliable way, across GCC versions, to write memcpy in pure C without having to worry that the compiler will translate it into a function that calls itself? Admittedly I would prefer flags that inhibit generation of calls to memcpy absolutely, but those don't seem to exist. Is it safe if I just avoid struct assignments? Or does bug 56888 mean I need to avoid struct assignments AND use special flags to turn off some optimizations? Are there other conditions under which gcc generates calls to memcpy? Please keep me CC'd in replies as I am not a subscriber to the list. Rich
