Hi everybody,
I’m porting quite a large code to GPU and having some problems getting the initial port running.
Does anyone now what the problem could be when this error “Internal compiler error. unsupported procedure” is thrown up?
Cheers,
Crip_crop
Okay a little more information about my errors. This is what is getting thrown up:
PGF90-S-0000-Internal compiler error. unsupported procedure 491 (cart_force.f: 593)
PGF90-S-0000-Internal compiler error. unsupported procedure 491 (cart_force.f: 593)
device_dener:
360, Memory zero idiom, array assignment replaced by call to pgf90_mzero8
361, Memory zero idiom, array assignment replaced by call to pgf90_mzero8
0 inform, 0 warnings, 2 severes, 0 fatal for device_dener
PGF90-S-0000-Internal compiler error. unsupported procedure 412 (cart_force.f: 861)
device_overlp:
675, Memory zero idiom, array assignment replaced by call to pgf90_mzero8
0 inform, 0 warnings, 1 severes, 0 fatal for device_overlp
device_ssmndo:
973, Invariant assignments hoisted out of loop
974, Invariant assignments hoisted out of loop
975, Invariant assignments hoisted out of loop
976, Invariant assignments hoisted out of loop
/tmp/pgcudafor-N5g9oojuX6k.gpu(2704): error: expected an identifier
/tmp/pgcudafor-N5g9oojuX6k.gpu(2988): error: expected a “(”
/tmp/pgcudafor-N5g9oojuX6k.gpu(2990): error: expected an expression
/tmp/pgcudafor-N5g9oojuX6k.gpu(2994): error: expected a “(”
/tmp/pgcudafor-N5g9oojuX6k.gpu(2996): error: expected an expression
/tmp/pgcudafor-N5g9oojuX6k.gpu(3000): error: expected a “(”
/tmp/pgcudafor-N5g9oojuX6k.gpu(3002): error: expected an expression
/tmp/pgcudafor-N5g9oojuX6k.gpu(3012): error: expected a “(”
/tmp/pgcudafor-N5g9oojuX6k.gpu(3014): error: expected an expression
9 errors detected in the compilation of “/tmp/pgnvdZO5gzjCaJeSx.nv0”.
PGF90-F-0000-Internal compiler error. pgnvd job exited with nonzero status code 0 (cart_force.f: 5226)
PGF90/x86-64 Linux 10.8-0: compilation aborted
make[1]: *** [cart_force.o] Error 2
I’d really appreciate it if anyone could shed a little light on this situation.
Cheers,
Crip_crop
Crip_crop,
This probably isn’t the answer to your error (since I don’t know what procedure 491 is), but when I last encountered a “Internal compiler error. unsupported procedure ###” it was due to the GPU compiler trying to allocate memory on the GPU, something that isn’t allowed. (I only knew this because I’d asked PGI what my error meant.)
Eventually I was able to track it down to a calculation being done in a call to a device subroutine. That is, I had
call run_xyz(matrix1, matrix2, matrix3/air_const)
where air_const was a constant. This is quite fine on the CPU, but it turns out on the GPU the compiler was trying to allocate a temporary array, put the result of matrix3/air_const into that new array and then pass that array to the subroutine. That’s a no-go. (I could solve this by either passing the constant into the subroutine and dividing there or making my own working array outside, do the division, and pass the resulting array into the call.)
As for the others, hmm, the only way to maybe track those down is to look at the resulting .gpu file, find what line the error references (since, say, 2704 is the line in the .gpu, not in your original code), and see if you can figure anything out. In the end, you might have to send the code to PGI.
Wish I could help more,
Matt
Thanks for replying.
Now this may seem like a really simple thing but, how do I know what unsupported procedure ### is? Is there a way of knowing? If I knew which procedures it was failing to compile on then I might have a better chance of fixing the problem.
Cheers,
Crip_crop
I don’t think there is a translation guide to those numbers. I think the folks at PGI have a way of translating them, so send them a test case that fails is probably the best bet of knowing.
The only thing I can say is that if your error is like mine (trying to alloc/dealloc on a GPU), then the line number it spits out (593 in your case, 1273 in mine) will be the “end subroutine” line of a subroutine which contains the error. I guess look at all the calls to other subroutines/functions in that subroutine and see if there are any calculations passed as reference. (I guess a full-on ALLOCATE would do it too, but I’d imagine the compiler spots those right off.)
Hi Crip_crop,
Now this may seem like a really simple thing but, how do I know what unsupported procedure ### is? Is there a way of knowing? If I knew which procedures it was failing to compile on then I might have a better chance of fixing the problem.
The ‘###’ only has meaning within the context of your program, so in order to know what the offending procedure is, we’d need to see an example. Can you please send a report to PGI Customer Service (trs@pgroup.com)?
As Matt points out, the error can occur when the compiler needs to create a temporary array when passing data to a subroutine. However, this is not the only case where this problem can occur.
Thanks,
Mat
Okay. Well I’ll send and example in. My code is rather large so I’m just going to send the offending subroutine and the subroutine that calls it.
Thanks for you help,
Crip_crop
PGF90-S-0000-Internal compiler error. unsupported procedure 491 (cart_force.f: 593)
PGF90-S-0000-Internal compiler error. unsupported procedure 491 (cart_force.f: 593)
device_dener:
360, Memory zero idiom, array assignment replaced by call to pgf90_mzero8
361, Memory zero idiom, array assignment replaced by call to pgf90_mzero8
It seems that any unsupported function call generates this obscure message. I tried to do bit manipulation on an interger(8) and go the same. I bet that attempting to compute a cosine of a real*8 will cause the compiler to crash similarly. The rest of the error message suggests, but this is a wild guess on my part, that your code tries to do something like “array=0” to zero an array and generates an unsupported subroutine call to accomplish this. Look at line 593 of cart_force.f and you may find out what is causing the problem.
Peter.
I remember that a while back, I had a CUDA Fortran code that wouldn’t compile under -Mcuda and -fast due to an “array=0” line. If I removed the -fast from the compilation of that file, it would then pass through without the ICE (I suppose because instead of mapping that array=0 to a pgf90_mzero4 or whatever, it just did the plain, ol’ loops.) If the zero’ing replacement call isn’t being properly detected/ignored by the CUDA translator, it could be the same issue (I wouldn’t have seen zero8 since that code was all real*4).
In fact, I think I still do this in that routine because, really, with CUDA Fortran -fast or not doesn’t make much difference with the GPU code, I don’t think.
Hi All,
Yes, crip_crop’s issue was the due to idiom replacement. This problem was fixed in the 10.9 release.