Originally posted here: http://gcc.gnu.org/ml/gcc-help/2010-04/msg00233.html
Consider the following code: sal...@salmin:~$ cat restrict1.c void f(int *a, const int *restrict b) { *a++ = *b + 1; *a++ = *b + 1; } "const *restrict" guarantee that *b will not be modified inside f and we can eliminate a load in the second statement. However: sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99 restrict1.c sal...@salmin:~$ grep -v '[.:]' restrict1.s movl (%rsi), %eax addl $1, %eax movl %eax, (%rdi) movl (%rsi), %eax addl $1, %eax movl %eax, 4(%rdi) ret But if we add a restrict keyword to the "a" definition it helps surprisingly: sal...@salmin:~$ cat restrict2.c void f(int *restrict a, const int *restrict b) { *a++ = *b + 1; *a++ = *b + 1; } sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99 restrict2.c sal...@salmin:~$ grep -v '[.:]' restrict2.s movl (%rsi), %eax addl $1, %eax movl %eax, (%rdi) movl %eax, 4(%rdi) ret Not sure if it's a duplicate bug, other restrict-related bugs I've checked seemed different to me. -- Summary: yet another missed restrict optimization Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alexey dot salmin at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43907