https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70055
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Wilco from comment #6) > (In reply to Jakub Jelinek from comment #4) > > Note the choice of this in a header file is obviously wrong, if you at some > > point fix this up, then apps will still call memcpy rather than mempcpy, > > even when the latter is more efficient (because it doesn't have to save the > > length value in some location where it survives across the call). > > Note if you don't use the result of mempcpy, gcc is able to optimize it into > > memcpy, and tons of other optimizations. > > It's highly unlikely that calling mempcpy would ever provide a performance > gain. There is no reason why the memcpy vs. mempcpy calls should not be the same speed (+/- a cycle or 3, but it can actually be that mempcpy may be faster). The gain is on the caller side, mempcpy allows for more compact and faster code in quite common case. By sticking the bogus __mempcpy_inline you pessimize apps until they are recompiled, no matter whether glibc is fixed in the mean time or not.
