the correct use is to go with the "restrict" as keyword. If you're using anything else than C99 (the only one this keyword is specified for) you have to supply the "-restrict" (Linux* or Mac OS* X) or "/Qrestrict" (Windows*) option to enable it.
The "__restrict" & "__restrict__" keywords are mostly internal and should not be used. However, they still work even without supplying any additional compiler option.
all those keywords work the same for Intel® C++ Compiler. However, the internal versions are least portable and hence not recommended.
So, whatever version you use you tell the compiler that pointers are not overlapping (more precisely their targets) - there are no other pointers to that location, as you say.
Edit: Another point that might be interesting for you, esp. when using the "restrict" keyword: Our Intel® C++ Compiler does not enable strict aliasing by default. So, if you're looking for performance and have ANSI compliant code you for sure also want to turn on "-ansi-alias" (Linux* & Mac OS* X) or "/Qansi-alias" (Windows*).
Microsoft has documented for several years the __restrict spelling. However, I haven't found any use for it in MSVC (it doesn't even pass syntax checking). It has the desired effect in Intel compilers, and in gcc/g++ (on many targets). The documentation on how portable this more widely used spelling may be for C++ is lacking, in my opinion. I don't see whether Georg would recommend the spelling which is acceptable to multiple compilers, or the use of #define macros to change among compilers. The latter seem better between MSVC and ICL.
Georg's point about setting -ansi-alias for Intel compilers (to get the equivalent of the gcc rather than Microsoft default) is a valid one.
Both ansi-alias option and restrict/__restrict are inherent in CEAN notation, so that provides an alternative way (of limited portability) to get those optimizations. I don't know if this means we are on shaky ground if we use CEAN in cases of possible data overlap. CEAN is marketed as part of the Cilk+ extension set for C or C++. Cilk+ introduces a few more somewhat obscure differences between C (C99 preferred) and C++.
Actually I put "aligned" and "align" and the compiler does not complain ... it is a bit confusing with all the variations of these keywords whether I'm using the right one or more importantly if the compiler is getting to do what I intend it to ...
I hope the documentation is only preliminary. The spelling __declspec(align(32)) is documented there. Clearly, there have been urgent requests to support also the documented gcc spelling __attribute__((aligned(32))) (on both linux and Windows). I hope that version was tested. I agree entirely that the subject should not be confused with new spellings when there are already working Microsoft and gcc spellings for this feature.