Neither of your options is the actual rule. The actual rule is that when the program runs, there can't be any runtime aliasing.

You can totally call a subroutine with several arguments being the same thing, as long as you don't do anything bad inside the subroutine.

I'm aware of this because I tried to get the PathScale compiler team to add a warning for incorrect aliasing. That wasn't possible. But I did get a flag which made the compiler obey C aliasing rules for Fortran, and it was part of the "got the wrong answer? run with these flags and if you get the correct answer, your program is not standard-conforming" thingie.

Please educate me and explain how that contradict anything I claimed, as I don't see it.

I claim it is only a promise, you claim you can call it with identical arguments. I don't see a contradiction; making a promise isn't the same as keeping it.

Similarly, your argument that it is fine to break that promise as long as you don't do anything bad inside the subroutine, I read as "you sometimes can get away with breaking a promise", but again, that's not the same as not making the promise.

What am I missing?

The difference is subtle. Here is a (stupid) example:

    int chooseone(restrict int* a, restrict int* b, bool c) {
       if(c) return *a; else return *b;
    }

Here, we can pass the same pointer for a and b, because only one of them is ever accessed in any call to the function.

Thanks. I reread http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, and initially didn't get that from the informal description of restrict given there. It says (section 6.7.3):

"An object that is accessed through a restrict-qualified pointer has a special association with that pointer. This association, defined in 6.7.3.1 below, requires that all accesses to that object use, directly or indirectly, the value of that particular pointer."

So, it hinges on the meaning of 'accesses'; it is a runtime thing, not a compile-time thing.