Neither gcc 5 nor clang 3.6 give warnings where the constraints of the restrict qualifier are violated, even when called with -Wall. Consider the following code fragment:
extern void f(char *restrict p, char *restrict q);
void g(char *p)
{
f(p, p);
}
Naively, I'd expect that the violation can be determined statically, and I was expecting that -Wall would give a warning. Have I missed a flag somewhere, or is there some problem with giving warnings that I'm not seeing?
Starting with version 8, gcc gives a helpful warning for the above code:
a.c: In function ‘g’:
a.c:5:5: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict]
f(p, p);
^
The restrict keyword is an explicit assurance from the programmer that the pointers in question don't alias. In essence, it allows the compiler to omit alias analysis for those pointers, because the programmer has already provided the presumed answer. In addition to enabling better optimization, this can also save compilation time. In large programs, analysis can be quite expensive, so that's potentially a big deal in its own right.
So, the answer to your question is, I believe, "the compilers aren't looking, because the code tells them not to bother"
Given the code:
void test(int *restrict a, int *restrict b, int c)
{
a[0] += b[c];
}
the only scenario affected by the restrict qualifier would be a==b+c;
in that case, the pointer in a would be used to modify an object which is
also accessed through unrelated pointer in b. In all other cases that
would be defined in the absence of restrict, no object that is accessed
via a would also be accessed via b, nor vice versa.
A compiler that could see that a function that was passed restrict-
qualified pointer arguments used them in violation of the rules associated
therewith might helpfully warn of such violation, but a compiler that can't
see into a function would have no way of knowing what combinations of
arguments would be valid or invalid.