Tobias Burnus <bur...@net-b.de> writes: > Would it? How does the compiler know that between "call > SYNC_calling_proc()" the value of "coarray" could change? Hmm, > seemingly, that's indeed the case, looking at the optimized dump of > the example above:
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. > Well, then I have a different question: How can one tell the middle > end to optimize the "if (...)" away in the following case? Seemingly > having an "integer(kind=4) & restrict non_aliasing_var" does not seem > to be sufficient to do so: > > subroutine sub(non_aliasing_var) > interface > subroutine some_function() > end subroutine some_function > end interface > > integer :: non_aliasing_var > non_aliasing_var = 5 > call some_function() > if (non_aliasing_var /= 5) call foobar_() > end subroutine sub > > That's an optimization, which other compiles do - such as NAG or > PathScale/Open64/sunf95. >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? Ian
