https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #20 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #18) > Plus, ASYNCHRONOUS means that the variable can change even in > the absence of a call, so > > CALL FOO (A) > A = 2 > IF (A == 2) THEN > > could not be optimized and would need a reload from memory of A, because > we are telling the compiler there could still be a pending I/O left over > which changes the value of A between the assignment and the comparison. No. We aren't talking about volatile memory, and this example is shortened too much. The above is simply undefined code with ASYNCHRONOUS. MPI has several more or less explicit barriers. In the original testcase, it is MPI_WAIT. So it is more like: CALL FOO (A, request) CALL MPI_WAIT (request, ...) A = 2 IF (A == 2) THEN This is a semantically explicit guarantee by the programmer that A does not change after the MPI_WAIT, even if it cannot be expressed in Fortran. (Ironically, even request changes after return from FOO...)
