On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei <b...@broadcom.com> wrote:
> Hi,
> I am working on how to improve "restrict". I noticed
> that my changes lead to failure of pr38212. After looking
> at its code, I think the test may not be valid according
> to c99 standard.
>
> C99 standard 6.7.3.1:
>
> EXAMPLE 4 The rule limiting assignments between restricted pointers does not
> distinguish between a
> function call and an equivalent nested block. With one exception, only
> ''outer-to-inner'' assignments
> between restricted pointers declared in nested blocks have defined behavior.
> {
> int * restrict p1;
> int * restrict q1;
> p1 = q1; // undefined behavior
> {
> int * restrict p2 = p1; // valid
> int * restrict q2 = q1; // valid
> p1 = q2; // undefined behavior
> p2 = q2; // undefined behavior
> }
> }
>
> pr38212.c
> int __attribute__((noinline))
> foo (int *__restrict p, int i)
> {
> int *__restrict q;
> int *__restrict r;
> int v, w;
> q = p + 1;
> r = q - i;
> 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;
> }
>
> Isn't that "r = q - i" undefined?
Why? r is based on q which is based on p. If you write the source
as r = p + 1 - i; it'll have the same effect (and then it's clearly based on p).
"q = p + 1" may be also undefined,
> depending whether we regard parameter p from outer or inner block.
you can avoid all the named temporaries by substituting the
pointer arithmetic into the dereferences.
Of course the middle-end may not do optimizations based on what
C thinks are "blocks".
Richard.
> Cheers,
> Bingfeng
>
>
