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