Re: mips64 n32 and n64 support in dl-machine.h

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 14, 2003, Andreas Schwab <schwab at suse dot de> wrote:

> Alexandre Oliva <aoliva at redhat dot com> writes:
> |> On Mar 14, 2003, Roland McGrath <roland at redhat dot com> wrote:

> |> >> Hmm...  Good point.  As far as I can tell from looking at
> |> >> expand_builtin_memcpy, casting the possibly-mis-aligned pointer to
> |> >> (char*) should be enough to fix it, no?

> I don't think this is enough.  You'll probably need to alias the original
> pointer with a pointer to a packed type.

And why would this be guaranteed to work?  A sufficiently smart
compiler might very well know that the pointer to the packed type
aliases the original pointer, and therefore conclude it must be
aligned.

I guess there's no escaping of some asm copying here :-(

> The point is that if you have an unaligned pointer to begin with, all bets
> are off (undefined behaviour).

Dereferencing the pointer would be undefined behavior, except if
accessing the data as raw memory (through char), which is what memcpy
is supposed to do anyway.

The problem here is that the compiler legitimately assumes that a
pointer is aligned, but we have to turn that into a pointer that's not
guaranteed to be aligned while preventing the compiler from being
smart and figuring out the pointers are the same and doing the
optimization anyway.  I can only think of two ways to do it: inline
assembly (asm ("" : "=r" (unaligned) : "0" (aligned))) or a function
in a separate translation unit (which might break as soon as we got
whole-program optimizations).  I'm going with the former.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva at {redhat dot com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva at {lsd dot ic dot unicamp dot br, gnu.org}
Free Software Evangelist                Professional serial bug killer