(j3.2006) How to find out if a compiler supports ASYNCHRONOUS attribute outside of I/O

[Tobias Burnus]

Rasmussen, Craig E wrote:
> For MPI we want to add a flag to see if the ASYNCHRONOUS attribute can be used to turn off aggressive optimizations for code outside of I/O.  Unfortunately I can't think of a runtime test that can be applied across all compiler that can provide this information.

I hope that the ACM Fortran Forum's Fortran 2003/2008 implemention 
status articles [1] will contain in the future also a status list for TR 
29113 - including ASYNCHRONOUS.

[1] For the current version (F2003 and F2008 only), see at 
http://dx.doi.org/10.1145/2007333.2007335 or the current-minus-one 
version at 
http://www.fortranplus.co.uk/resources/fortran_2003_2008_compiler_support.pdf

> Hopefully this information might be in documentation but it is very hard to distribute software that is based on documentation alone.  It is much easier to right a runtime test if possible. Any ideas as to how to find out if aggressive optimization is turned off with the ASYNCHRONOUS attribute?
>

I have some ideas - however, I don't think there is a reliable way to 
detect it. Tests are likely beyond that what is allowed by standard and 
might have both false positives and false negative results. In 
particular, inlining settings, link-time optimization and 
architecture-dependent optimization can influence the result - such that 
optimizations might be done differently for the test case than for the 
real program.

Some idea for a test - requiring two files:

   use m
   integer, asynchronous :: a
   call init (a)
   a = 5
   call finalize()
   if (a == 5) error stop "No asynchronous support"
   end

using something like:

   module m
      integer, pointer :: p
   contains
      subroutine init(x)
          integer, target :: x
          p => x
      end subroutine  init
      subroutine finalize()
          p = 7
      end subroutine finalize
   module m

which should have the desired effect. Note, however, that accessing "p" 
after "init" has returned (i.e. in finalize) is beyond the spec; though 
in practice it hopefully works with most compilers. And with link-time 
optimization, the compiler could inline the code - and thus effectively 
disabling the check.

Tobias

PS: In case of gfortran: GCC shouldn't do optimizations which would 
violate ASYNCHRONOUS (even without the attribute). It's planned to do 
more aggressive optimization in the future -- but not for variables 
which are marked as asynchronous.