Correct, scalar variables in a parallel region are implicitly defined as first private. The exceptions being when used in a reduction, used in a data clause, a live-out variable, is a module variable (or a global reference), or passed by reference to a device routine.
Given “i” is assigned in the parallel loop and then used on the host after the loop, the compiler warns about a “Scalar last value needed after loop for i at line 12”. This forces “i” to be a shared rather than private variable. Otherwise, the code would get differing answers depending if you’re running with or without OpenACC. This is really a bug in your code since a live-out variable can prevent parallelization and can cause inconsistent behavior between the host and device. .
% nvfortran -fast -acc test4.F90 -Minfo=accel -V20.5 ; a.out
7, Scalar last value needed after loop for i at line 12
Generating Tesla code
Generating implicit copyout(j(1)) [if not already present]
Scalar last value needed after loop for i at line 12
Now you can override the implicit behavior by explicitly adding a “firstprivate(i)” or “private(i)” clause on the parallel region, but you would get incorrect answers.
Incidentally, gfortran (GCC) compiled code gives expected output.
GNU’s analysis isn’t quite as comprehensive as ours so they probably miss the live-out variable so go ahead and implicitly treat “i” as first private. So while “i=10” is what you expect, it is wrong with respect to the answer you’d get running on the host. At the very least, they should be giving you a warning about the live-out variable so you have an opportunity to fix this bug in your code.