Aleksandar Donev writes: > Hi, > I just also included double precision reals in my Radix sort and got a > compiler warning for: > real(kind=r_64) :: real_64 ! Double-precision on my machine > integer(kind=i_64) :: integer_64 ! Also double precision > EQUIVALENCE(real_64, integer_64) > because double-precision integers are not in the standard set of types. This > is somewhat annoying and I don't see a reason for it. With the usual caveat about it being hard to say what reasons for, it's really not difficult to guess what is behind the equivalence limitation on kinds other than the f77 ones. I was not there when this f90 decision was made. Nor have I talked about it with any of the people who were....mostly because it seemed "obvious" enough to me that I didn't have to ask about it. It isn't standard because it would break portability. The standard tends to disallow things that will result in different behavior on different platforms. That doesn't mean it might not be supported on the individual platforms, but the results might be different. For the non-character f77 type kinds, the f77 standard established (and the f90 standard retains) relative sizes in terms of "numeric storage units". For example, a double precision always takes exactly 2 numeric storage units. Even if all the bits might not be usefully used, you are guaranteed that a double precision will take twice as much space as a single precision. Etc. Thus the equivalence relationships are all defined by the standard. For other kinds, the standard does not establish the relative sizes. *YOU* may happen to know that you have arranged things so that integer(kind=i_64) takes the same space as your real(kind=r_64), but that is not a portable assumption. The same code on another machine might not have this property (depending on exactly how you defined your kinds). You may have been pretty careful about arranging that this will be true, but the compiler and the standard doesn't know that you have been careful about that (and I absolutely guarantee you that a lot of other people haven't). This isn't, by the way, a particularly new thing to f90. F77 had a simillar restriction for what I presume to be a simillar reason. F77 disallowed equivalence of character and non-character data because the relative sizes of character and numeric variables varied among machines (no "might vary" here - they *DID* vary). Thus if you equivalenced a character array to a numeric array, the equivalence relation would have been quite different on different machines. Yes, some (but not all) f77 compilers allowed this equivalence anyway, but it wasn't standard and wasn't portable among different platforms. F77ish example (illegal one) character*80 c integer(20) i equivalence(c,i) c = 'some stuff' i(2) = 0 Now which characters in c are still defined? Assuming, of course, that your compiler accepts this extension. The answer is that it depends. On an old CDC machine (if they accepted the code), it would be all except for c(11:20). On Crays it would probably be all except for c(9:16). On a lot of other machines, it would be all except for c(5:8). This is exactly the kind of machine variation that the standard tends to stay clear of. If you depend on things like this, then completely different things will happen on different machines (and one of the different things is likely to be that it doesn't compile at all on some). Wouldn't suprise me to find that some f90 compilers allow an extension here (in fact, I'm pretty sure of it). -- Richard Maine | Good judgement comes from experience; [log in to unmask] | experience comes from bad judgement. | -- Mark Twain