This is the mail archive of the mailing list for the glibc 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]

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

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.  Note that get_pointer_alignment
peeks through casts to find the maximum possible alignment.

|> > That's what the C standard says.
|> I can't find any such language in the standard.  Besides, the Standard
|> knows nothing of __builtin_memcpy: that's a GCC extension :-)

__builtin_memcpy is just the same as memcpy, so anything you can say about
memcpy also applies to __builtin_memcpy.

|> What
|> the Standard says about memcpy() could be relevant, to a point, but
|> all it seems to say is that memcpy copies the given number of
|> characters from source to dest.  No mention of alignment, since it's
|> all accessed as char anyway.

The point is that if you have an unaligned pointer to begin with, all bets
are off (undefined behaviour).  Thus the compiler can assume that the
pointer is correctly aligned for the original type and optimize
accordingly.  Even if the mips backend does not currently take advantage
of that it might do in the future.  Other backends already do, AFAIK.


Andreas Schwab, SuSE Labs, schwab at suse dot de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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