https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111722
--- Comment #5 from Zeb Figura <zfigura at codeweavers dot com> --- (In reply to Andrew Pinski from comment #4) > There is no bug here. > ICF finds that your definition of memcpy is the same as memmove and merges > the 2 and then calls memcpy from your memmove and then inlines the normal > memcpy because well it says it is the same. I suppose I understand this explanation, but it does not feel like a very intuitive behaviour. The ICF part makes sense. The choice to optimize a builtin memcpy/memmove call into a different instruction sequence (which doesn't match the original) also makes sense. I would not really expect these two to be combined in this manner, though. memmove() is not calling builtin memcpy(), it is calling our implementation of memcpy(), which doesn't have the same semantics as builtin memcpy(). [It also seems odd to me that func2() would be replaced with a builtin memcpy() rather than a builtin memmove()?] > You can just use -fno-builtin to fix the issue by saying memcpy and memmove > are not builtins and treat them like normal functions. > > That fixes the issue by not inlining the target defined memcpy. Fair enough, I guess. I suppose that's the right thing to do anyway...
