On 01/10/11 16:19, Somebody in the thread at some point said: > Quoting Andy Green<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) > [...@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 *?
It's just noticing that we passed as unsigned char * when strcpy is built to want a char *, because of pedantic. That's nothing to do with alignment, and if you edit the buffer to be char [] instead of unsigned char [] there are no warnings, despite the alignment problem is still there the same. > 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 That is interesting... I also can see that if I give -Wcast-align on 4.4.2 on F12 Arm Fedora despite it doesn't appear with -Wall. However with this --> #include <stdio.h> #include <string.h> int main(int argc, char * argv[]) { char buf[8]; void *v = &buf[1]; unsigned int *p = (unsigned int *)v; strcpy(buf, "abcdefg"); printf("0x%08x\n", *p); return 0; } which is a very common construct that an unknown-typed pointer is passed into a callback API as a void *, but the callback knows its type and casts it, you still don't get any warning even with: gcc --pedantic -Wall -Werror -Wcast-align /tmp/x.c So it's not going to sniff out all the problems. Still, thanks for pointing that out. -Andy _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm