On Fri, Nov 21, 2008 at 10:14 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Michael Matz <[EMAIL PROTECTED]> 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?
Yes, the Intel compiler at least (version 9.1) behaves as bad as we do.
> 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.
I think we should try to implement a more sane and forgiving variant of
restrict - simply because not doing so makes many transformation GCC does
itself "violate" the restrict specification (for example just make PRE do
an insertion on a valid testcase - this would make it break again unless we
fix all GCC passes to properly update the based-on information).
Note that I am not suggesting we need to fix 4.4 or earlier versions - I am just
very confident that the current implementation using TBAA alias sets is
wrong.
Richard.
