https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 > > --- Comment #13 from Oleg Endo <olegendo at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #12) > > > > No, because the access is performed as 'int'. > > > > > > Why should memcpy be any different? > > > > Because the memcpy stmt doesn't constitute a memory access but a function > > call. > > Yeah, that might be how things are handled internally. But that doesn't mean > the optimization in question can't / shouldn't be done. GCC does even more > "evil" things with function calls such as replacing printf with puts, > propagating arguments into functions, inlining... So ... uhm ... I'm afraid I > don't get the point. The point is the only reason you can do the optimization (on all targets) is that C standard rule about pointer types (casting). GCCs implementation details will make the application of the optimization quite unreliable as well. I've repeatedly said that I think relying on that part of the C standard with respect to undefinedness would be a bad thing from a QOI perspective. But I've changed my mind in the past - does -fsanitize=alignment instrument pointer types/casts?
