This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Restrict implementation considered harmful
On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <iant@google.com> wrote:
> Michael Matz <matz@suse.de> writes:
>
>>> This program appears to me to be invalid according to C99 6.7.3.1,
>>> which is the only definition of restrict that we have.
>>>
>>> If P is assigned the value of a pointer expression E that is based
>>> on another restricted pointer object P2, associated with block B2,
>>> then either the execution of B2 shall begin before the execution
>>> of B, or the execution of B2 shall end prior to the assignment.
>>> If these requirements are not met, then the behavior is undefined.
>>>
>>> In your program, P is q and P2 is p. Block B and B2 are the same
>>> block: the only block in foo. It is obviously not the case that the
>>> block executes before itself. So I believe the assignment "q = p + 1"
>>> is undefined behaviour.
>>
>> But the testcases in the PR can easily be transformed to fulfill this
>> requirement. E.g.:
>>
>> int __attribute__((noinline))
>> foo (int *__restrict p, int i)
>> {
>> if (1)
>> {
>> int *__restrict q = p + 1;
>> if (1)
>> {
>> int *__restrict r = q - i;
>> int v, w;
>> v = *r;
>> *p = 1;
>> w = *r;
>> return v + w;
>> }
>> }
>> }
>> extern void abort (void);
>> int main()
>> {
>> int i = 0;
>> if (foo (&i, 1) != 1)
>> abort ();
>> return 0;
>> }
>>
>> This (and the other testcases similarly changed) still break.
FWIW, I believe most other compiler get restrict "wrong" just as badly
as us when it comes to "based on" pointers.
Didn't you also find this to be the case, Richard?
It is going to be roughly impossible to be conformant unless we
propagate restrict around in the actual frontends, which still have
actual block information.