On 07/13/2011 03:27 PM, Ian Lance Taylor wrote:
The C99 restrict qualifier doesn't mean that some random function can
change the memory to which the pointer points; it means that assignments
through pointer 1 can't change the memory to which pointer 2 points.
That is, restrict is all about whether one pointer can affect another;
it doesn't say anything about functions, and in general a call to a
function can change any memory pointed to by any pointer.
That was actually my impression - thus, I wanted to have a different 
flag to tag asynchronous/coarray variables, which do not alias but might 
change until a synchronization point via single-sided communication or 
until a wait with asynchronous I/O/communication. As one does not know 
where a synchronization/waiting point is, all code movements and 
variable value assumptions (of such tagged variables) should be 
prohibited across impure function calls.
By contrast, for a normal Fortran variable without POINTER or TARGET 
attribute does not alias - and may not be changed asynchronously.
The latter is what I thought "restrict" (more precisely: 
TYPE_QUAL_RESTRICT) does, but seemingly it currently also does the former.
 From a C perspective, the trick here is to know that the address
"non_aliasing_var" does not escape the current function, and that
therefore it can not be changed by a function call.  gcc already knows
that local variables whose address is not taken do not escape the
current function.  I don't know how to express the above code in C; is
there something in there which makes the compiler think that the code is
taking the address of non_aliasing_var?  If not, this should already
work.  If so, what is it?  I.e., what does this code look like in C?
I am not sure whether there is a 100% equivalence, but it should match:

void some_function(void);

void
sub (int *restrict non_aliasing_var)
{
  *non_aliasing_var = 5;
  some_function ();
  if (*non_aliasing_var != 5)
    foobar_();
}

Also in this case, the "if" block is not optimized away with -O3.

Tobias

PS: See also just-filled PR middle-end/49733.

Reply via email to