Quoting Andy Green <andy(a)warmcat.com>:
On 01/10/11 12:23, Somebody in the thread at some point said:
>>> Even on x86 it may not always generate code that does what you want:
>>> gcc is perfectly entitled to assume that an unaligned pointer is
>>> never used. And even now, x86 has a big performance hit for word
>>> accesses that straddle a cache line boundary.
>>
>> I don't know about gcc being able to discard unaligned pointers, and
>> have never observed it to my knowledge. That's just a "C lawyer"
>> possibility or actually can happen?
>
> Both. It doesn't happen, but according to the language specification
> it could. However, we've seen quite enough of "this is only a
> language lawyer's theoretical possibility" bugs turning into real
> bugs.
Well, with --pedantic -Wall -Werror gcc doesn't care to warn about the
unaligned pointer test x.c I posted the other day (not even with a
static byte buffer) and produces code using the pointer correctly. So I
think you're right with gcc at least silently dropping a misaligned
pointer "doesn't happen" and I still don't know what the basis is that
it could happen.
I agree though having been bitten by it myself with mIsdn a guy just
casting things unaligned is at least writing nonportable code and should
be able to be written better. There're benefits even on x86 and ARM
with hardware fixup so it's hard to argue against.
I think you will find this interesting.
on fc14 i586 gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
[so@bk14 ~]$ gcc --pedantic -o x x.c
x.c: In function ?main?:
x.c:9:2: warning: pointer targets in passing argument 1 of ?strcpy?
differ in signedness
/usr/include/string.h:128:14: note: expected ?char * __restrict__? but
argument is of type ?unsigned char *?
Also if you add -Wcast-align gcc version 4.3.2 (Debian 4.3.2-1.1) on
the guruplug, you actually get
x.c:7: warning: cast increases required alignment of target type