This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/50417] regression: memcpy with known alignment


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 rguenther@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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]