After compilation test1.c with -O2 program loops unending.. Yeah I know is possible cause -fstrict-aliasing and program works compilated with -O2 && -fno-strict-aliasing It works too if it was compilated just only with -fstrict-aliasing so it loops when some other optimization was turned on. It works too (not loops unending) if in loop while (* ((char *) str)) we `printf("0x%x\n", str);` (maybe some other code which evaluate and use that exp works too, i don't really know) [test2.c] If it's not gcc bug, I'm really sorry inconvience.. (something code like that was used in ekg2 #v+ (functions: http://webcvs.ekg2.org/_checkout_/ekg2/plugins/ncurses/ecurses.c?rev=1.3 usage: while (__S(str, 0)) { /* while (*str) */ __SN(&str, 1); /* str++ */ attr++; } loops unending, however if __SN() was declared not inline it works... for me it was really strange, in testcases keyword 'inline' doesn't change behavior. #v- If it's not gcc bug, but mine, once again i'm really sorry... Sorry for me English too. testcase tested with: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1) gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5) gcc (GCC) 4.1.0 (SUSE Linux)
Created attachment 12490 [details] First testcase First testcase loops unending with -O2, not loops with -O2 -fno-strict-aliasing || -fstrict-aliasing -O1
Created attachment 12491 [details] Second testcase test1.c + added printf() to loop, not loops with -O2
By the way, it's possible to fix the code in other way than using unions? It just need to work both for wchar_t strings and normal strings... If you have some ideas how, it'll be nice if you give me some hint... maybe use char * everywhere and use: real_char_index = index * (config_use_unicode * sizeof(wchar_t)) ?
In the both case, you are accessing "wchar *" via "char *" which causes an alias violation.
Yeah, I know, but why gcc generate good code if we add that printf to test1.c (test2.c) ? It's still wchar * -> char * still aliasing violation. or if we replace: __SN(&str, 1); with str = (CHAR_T *) (((char *) str) + 1); it generate good code too. it's still aliasing violation?
(In reply to comment #5) > Yeah, I know, but why gcc generate good code if we add that printf to test1.c > (test2.c) ? It's still wchar * -> char * still aliasing violation. Yes but there is a barrier which cause optimizations not to happen. > > or if we replace: > __SN(&str, 1); with > str = (CHAR_T *) (((char *) str) + 1); > > it generate good code too. it's still aliasing violation? No, that is legal as you are not accessing str (wchar_t*) as a "char*" any longer but as a "wchar_t*". You access str as a "wchar_t*" and then cast that value to a "char*" and then add one and then cast back to "wchar_t*" which causes the above code to be valid and defined.
Ok, one more question, is it possible to gcc print some warnings about code like that? Cause even with -Wall it doesn't ;( gcc4 is quite more verbose than gcc3 so I think It'll be better to print warning about situation which doesn't even generate invalid code... which actually -Wstrict-aliasing does (according to manpage), but neither -Wstrict-aliasing nor -Wstrict-aliasing=2 prints warning in that testcode... I hope it's possible, thx for all.