Quoting Andy Green <andy@xxxxxxxxxxx>: > 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
