%\pagebreak
\begin{fortranspecific}[4ex]
\section{Fortran \bcode{ASSOCIATE} Construct}
\label{sec:associate}
\index{ASSOCIATE construct, Fortran@\bcode{ASSOCIATE} construct, Fortran}

The following is an invalid example of specifying an associate name on a data-sharing attribute 
clause. The constraint in the \docref{Data Sharing Attribute Rules} section in the OpenMP 
4.0 API Specification states that an associate name preserves the association
with the selector established at the \bcode{ASSOCIATE} statement. The associate 
name \ucode{b} is associated with the shared variable \ucode{a}. With the predetermined data-sharing 
attribute rule, the associate name \ucode{b} is not allowed to be specified on the \kcode{private} 
clause.

%\pagebreak
\fnexample[4.0]{associate}{1}

In next example, within the \kcode{parallel} construct, the association name \ucode{thread_id} 
is associated with the private copy of \ucode{i}. The print statement should output the 
unique thread number.

\fnexample[4.0]{associate}{2}

The following example illustrates the effect of specifying a selector name on a data-sharing 
attribute clause. The associate name \ucode{u} is associated with \ucode{v} and the variable \ucode{v} 
is specified on the \kcode{private} clause of the \kcode{parallel} construct. 
The construct association is established prior to the \kcode{parallel} region. 
The association between \ucode{u} and the original \ucode{v} is retained (see the \docref{Data Sharing 
Attribute Rules} section in the OpenMP 4.0 API Specification). Inside the \kcode{parallel}
region, \ucode{v} has the value of -1 and \ucode{u} has the value of the original \ucode{v}.

\topmarker{Fortran}
\ffreenexample[4.0]{associate}{3}

%\topmarker{Fortran}
\label{sec:associate_target}

\bigskip
The following example illustrates mapping behavior for a Fortran
associate name and its selector for a \kcode{target} construct.

For the first 3 \kcode{target} constructs the associate name \ucode{a_aray} is
associated with the selector \ucode{aray}, an array.  
For the \kcode{target} construct of code block TARGET 1 just the selector
\ucode{aray} is used and is implicitly mapped,
likewise for the associate name \ucode{a_aray} in the TARGET 2 block.  
However, mapping an associate name and its selector is not valid for the same
\kcode{target} construct.  Hence the TARGET 3 block is non-conforming.


In TARGET 4, the \ucode{scalr} selector used in the \kcode{target} region 
has an implicit data-sharing attribute of firstprivate since it is a scalar.
Hence, the assigned value is not returned.
In TARGET 5, the associate name \ucode{a_scalr} is implicitly mapped and the
assigned value is returned to the host (default \kcode{tofrom} mapping behavior).
In TARGET 6, the use of the associate name and its selector in the \kcode{target}
region is conforming because the scalar firstprivate behavior of the selector 
and the implicit mapping of the associate name are allowed.  
At the end of the \kcode{target} region only the 
associate name's value is returned to the host. 
In TARGET 7, the selector and associate name appear in
an explicit mapping for the same \kcode{target} construct, 
hence the code block is non-conforming.

\ffreenexample[5.1]{associate}{4}
\end{fortranspecific}