[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#325670: gcc-4.0: regression: generates wrong code for inlined memcpy



On Tue, Aug 30, 2005 at 02:08:17PM +0200, Falk Hueffner wrote:
> Steve Langasek <vorlon@debian.org>, 325670@bugs.debian.org schrieb am 30.08.05 09:49:30:

> > When passing pointers to 4-byte types to memcpy(), gcc-4.0 generates
> > wrong code which assumes that these pointers are aligned at 4-byte
> > boundaries for purposes of optimization, ignoring the implicit cast to
> > (char *) in the prototype of memcpy().

> If a pointer points to an object that requires an alignment, then gcc can of
> course assume this alignment in the pointer. Later casting or passing of this
> pointer does not change this fact. If the pointer isn't actually aligned
> correctly for the object, then the error is already there (on the user's part),
> and the behaviour of memcpy is a red herring. So this is not a gcc bug.

By any chance, can you provide a reference to the C spec that shows
gcc's current behavior is valid?  Given that traceroute is among the
programs that breaks under gcc-4.0, it seems to me that the assumption
that it's safe to use memcpy this way has been around for quite some
time.

Note that we are talking about pointers that are used for *no* other
purpose than as a convenience for calculating offsets into buffers; the
pointers are never dereferenced by the code itself, and this unaligned
access is only happening because the gcc implementation of memcpy() is
making assumptions about its arguments that, AFAICT, it is not supposed
to be able to make.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: