I’ve been debugging my cuda extension and I’ve narrowed everything down to one final error (though I’m sure on correction it will move on to plenty more errors). What baffles me is that this error is thrown on line 60, which is preceded by 8 lines of the exact same declaration type, originating from the same module where they are also of the same data type.
In the imported module, the variable is declared as:
integer, parameter :: mz
I’ve imported it as:
use shared_laura_parameters, only :: … … h_mz=>mz, … …
and all other similar variables imported likewise
I’ve then defined the local variables as such:
integer, constant :: mz = h_mz
Error:
PGF90-F-0000-Internal compiler error. unsupported datatype 895
Despite the 8 identical (aside from variable names) declarations, an error is only thrown on this last line. Any ideas on what its angry about?
Edit: I kept the definitions at the module-level and moved the assignment statements to the host subroutine, which seemed to be at least avoiding the problem if not necessarily addressing the root cause. However, after moving all the problem variables, its now throwing the same type of error which it says occurs on line 2992. This particular file only contains 663 lines…
Hi rmsivley,
Internal compiler errors (ICE) are always problems with the compiler. Granted, they may be caused by some user semantic error, but in these cases the compiler should be catching the error not giving an ICE.
Would it be possible for you to send a reproducing example to PGI Customer Service (trs@pgroup.com)?
Thanks,
Mat
I’ll need to write an arbitrary example but I believe I understand the cause, even if I don’t understand the reason. I’ll try and send an email by the end of the workday.
Issues, I was writing two new modules, one to import from and one to import to. I’ve finished writing what I think will reproduce the error, but during compilation I get this error:
/usr/local/pgi105/linux86-64/10.5/lib/f90main.o: In function main': f90main.c:(.text+0x3c): undefined reference to MAIN_’
Could this have something to do with my troubles? Or is this just a simple oversight on my part? Code I have written:
module bug_reproduce
use bugged_import, only : h_bugged_parameter1 => bugged_parameter1, &
h_bugged_parameter2 => bugged_parameter2
implicit none
integer, constant :: bugged_parameter1 = h_bugged_parameter1
integer, constant :: bugged_parameter2
contains
attributes(host) subroutine bug_rep(random_var)
implicit none
integer, device, intent(in) :: random_var
bugged_parameter2 = h_bugged_parameter2
end subroutine bug_rep
end module bug_reproduce
This error just means that you don’t have a main program. Add “-c” to just compile and not link.
I see, not sure if I mentioned editing this existing code is my first fortran experience. Doesn’t look like my attempt at recreating the error succeeded with that code snippet. The issue may be more complicated than I thought. I will continue trying to reproduce it.
On a related note, is it part of your job with PGI to browse these forums? If so, is there a feedback option somewhere, because it would seem without your input these boards would be rife with problems and devoid of solutions.
On a related note, is it part of your job with PGI to browse these forums?
It’s not formally part of my job description, but I volunteered. I really enjoy the interaction with our users and like being able to better understand what issues people are having with our products.
If so, is there a feedback option somewhere,
I believe there’s a module I can add for feedback support, but I 'm not sure how helpful it would be. Let me think about it.
without your input these boards would be rife with problems and devoid of solutions.
We do have a few users (Thanks Matt) who help out as well, but yes, it is mostly PGI employees that answer posts. Though, I don’t think this is uncommon.
I’m having trouble recreating the error. I can’t seem to discover what is causing it well enough.
I have only one user-defined data type in the file, imported from another module, called ‘spec_prop’. It is used in the following declaration:
type(spec_prop), device, dimension(:) :: spec_propv
Could this be what is causing the unsupported data type error? Though wouldn’t the error be thrown on the correct line where this declaration occurs? I’m still getting like 2992 in a 676 line file.
Since I’m importing the user-defined data type from another module, do I need to redefine the data type in device memory somehow?
Also, does the 895 number in the error have any meaning?
more info on what it isn’t. I replaced all constant variables with device variables and it threw the same error, so I think that rules out the location in which I’ve declared those. Still no luck reproducing the error.
Could this be what is causing the unsupported data type error?
Possible. It could be how it’s being used (such as a conversion or being passes as an argument).
Though wouldn’t the error be thrown on the correct line where this declaration occurs?
Not necessarily. An ICE means that compiler has encountered something unexpected. The location from where the problem occurred and where it was caught could be completely different.
Also, does the 895 number in the error have any meaning?
The datatype number is an internal number which will vary depending on the actual program. So it’s only meaningful within the context of your program.
What I would suggest is to go back to the original failing case and start commenting out lines until the error goes away. This will give a better idea of the offending line.
Also, does your program have a device or global routine with a derived type dummy argument? We have an open report where the compiler was giving an ICE in this situation.
I did find that the data type contained a single variable with a pointer attribute. I am rewriting a new module with cuda-friendly contents and importing from there.
I tried that method and commented out all of the spec_prop and spec_propv references. It did remove the error, but only at the expense of many more errors (hit the max limit). Since I’m not seeing all errors, I can’t be sure that the error is resolved. It could very well be at the end of the list.
Is there any way that I could query my program to see which datatype is assigned the 895 value?
And lastly, no, the derived type variable is declared in device memory at the module level, so it is never passed as an argument.