Scalar variable live-out from loop

Accelerated Computing HPC Compilers Legacy PGI Compilers
#1

Hi,

There is a loop in the program I am working that gives the following restriction when compiled.

702, Accelerator restriction: scalar variable live-out from loop: .dY0022

It runs in parallel but does not do vector(256) even when explicitly defined. And I do not have any variable that resembles .dY0022. Anyone got any thoughts?

#2

Hi,

That is a compiler generated temporary variable for an optimized variable. There should be another similar message right before that one with the actual variable in your code. If you can fix that actual variable, this cryptic name should go away too.

Hope this helps.
Hongyon

#3

Here are the lines around that line:

       Generating copyin(h0(:))
  660, Generating !$acc update device(datin1(:,:))
  679, Generating !$acc update device(datinlns(:,:,:))
  688, Generating !$acc update device(seeds(:))
  699, Generating compute capability 1.3 binary
  702, Accelerator restriction: scalar variable live-out from loop: .dY0022
       Accelerator kernel generated
      702, !$acc do parallel

and also does anyone know what this means:

    703, Accelerator restriction: induction variable live-out from loop: ln2

thanks

#4

Hi,

Is it possible to either post snippet of your code that show the message or send something to trs@pgroup.com? So we can look at it and let you know how to avoid the the message Accelerator restriction.

Thank you,
Hongyon

#5

Here is the area around 702:
[/code] !$acc region do vector(256), parallel, private(iy,ix,k,stau,dl,alphadl,h,i,u,fudge, &
!$acc fn,starlns,nu0,vlam0,dvlam,dnudop,a,izkm,zfrac,z2,xr,gauslor,gauslor1,lorrnd,gaussrnd, &
!$acc rnd3,rnd2,rnd1,sigma1,sigma,prob,cul,t,star,flag,iflag,check,igarbage,c3,r2,r,phi,logrfp,rfp,alphapi,nu,shellsize)
do ln2 = 1,nlines
thetaout(ln2)=theta
iesc(ln2)=0

!initialize random num generator using the seeds created in the cpu
iy=ior(ieor(888889999,seeds(ln2)),1)
ix=ieor(777755555,seeds(ln2))

Line 702 is the do loop line.

the line:"induction variable live-out "in the diagnostics does not mean anything to us.

thanks

#6

Hi WmBruce,

‘live-out’ means that the variable’s value is being used after the accelerator region. For example, if the variable is used on the right-hand side of an expression or if it was passed into the function. The problem being that the compiler doesn’t know which thread’s value to store back into the CPU’s copy. The solution is usually to privatize the variable or remove the ‘live-out’ dependency.

The other possibility is that it’s compiler issue and in looking through our issue tracking system I do see one that is similar. In this case, the same ‘live-out’ error occurs when using an accelerator region within a contained subroutine. If this is the case for your code, then the only work-around is to make the subroutine independent of it’s parent routine.

If neither of these are helpful, can you please send a reproducing example to PGI Customer service (trs@pgroup.com)?

Thanks,
Mat

#7

thanks.

We don’t think it is the first choice as we changed its name so that it only occurred in the region.

The second case is doubtful as we expanded all the region code to in-line. We declare the region before the main loop and, after some preliminaries, do a region do vector, parallel, …

where the ln2 index variable occurs for the first time.

What is the prognosis for the method to be able to handle subroutines/function calls? In-lining makes the code long and fragile.

#8

What is the prognosis for the method to be able to handle subroutines/function calls? In-lining makes the code long and fragile.

No break through as of yet as we’re still hampered by the lack of a linker for the GPU. For CUDA Fortran on Fermi, we have developed a method to use device data from external modules (See http://www.pgroup.com/lit/articles/insider/v2n3a1.htm) which is good first step.

  • Mat