 |
 |
"Matt Challacombe writes: > My question: is this a compiler bug, or is it a F90 > implimentational error? If it is a compiler bug, does > anyone have a workaround?.. > INTEGER(KIND=8) :: I,K,Two Well, since there is no guarantee that KIND=8 is valid at all, much less happens to mean an 8-byte integer, all bets are off here. > Here is the second instance:... > PGF90-F-0000-Internal compiler error.... This seems like a pretty explicit answer to part of your question. When the cimpiler itself tells you it got an internal compiler error, it is invariably correct. :-) Count this one as a compiler bug. I couldn't tell you much about workarounds. Try asking PGF. (Though if this is their free one, I suppose it likely comes with no support). > Also, I was unable to get the NAG f90 compiler to give anything > else than a -1 for SELECTED_INT_KIND(R), with R being near 18. Although NAG supports 8-byte integers on some platforms, I don't think that is one of them. If integers that big aren't supported, then -1 is what you are supposed to get. > I'd very much appreciate any workarounds for dealing with these 64 bit > integer problems with either the pgf90 or NAG f90 compilers and/or > comments on my programming. It is possible (but painful and inefficient) to implement a user-defined type for large integers. I suspect a better approach would be to bug the vendors to get their act together on such support. Admitedly a single user complaint isn't likely to be enough, but enough such complaints is exactly what it takes to make such things happen. -- Richard Maine [log in to unmask] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%