Since Fortran 90, dead zones in data structures have meaning. For
example in N1601.pdf, section 13.7.121:

"If D is an array and E is an array of rank one, the value of
TRANSFER(TRANSFER(E,D),E,SIZE(E)) shall be the value of E."

Thus TRANSFER has to write bits as specified into the dead areas of
data structures and read them back out again, so the dead areas of
data structures can hold good data and should not be messed around
with at unawares by the Fortran processor (IMHO). However:

C:\gcc_mingw64a\test>type ACOSH_c10i.f90
program test
complex(10) z
z = (2.5,0.1)
call xfinit
call sub(z)
end program test

James Van Buskirk comcast.net> wrote:

I think you are reading far more into that specification than is really
there. I'm afraid that the posted code is just too much work for me to
interpret without spending more time and/or getting more help on it. I
don't exactly find TRANSFER to be easy to follow in the best of
situations, and I suspect this isn't the best of situations. However, I
think I have at least a guess at what you are getting at. If my guess is
correct, then I disagree with your conclusions.

1. I really wish that the above bit of the standard would have been more
qualified. It is my belief that there are cases where things simply
cannot work quite literally like that, or even if it is vaguely...

Richard Maine wrote:
(snip)

I think you are right, but it would have caused problems
when REAL variables were used with the A format descriptor
for character I/O (in Fortran 66 days). S/360 doesn't
normalize on assignment, so it worked there when I used it.

-- glen

Richard Maine wrote:

X86 processors convert a signaling NaN to a quiet NaN on assignment. I
have seen this bite many programs that inadvisedly used REAL variables
to do arbitrary datatype copying and found that the bit patterns changed.

On May 26, 4:33 am, glen herrmannsfeldt ugcs.caltech.edu> wrote:

"James Van Buskirk" comcast.net> writes:

"Charles Coldwell" gmail.com> wrote in message
news:rzpod6mmzei.fsf@gmail.com...

It's more complicated than that. Actually a REAL(KIND=10) variable
takes up 16 bytes on the compiler in question (gfortran for 64-bit
Windows). I gather that some if not all compilers which implement
REAL(KIND=10) variables on 32-bit Windows pad them out to only 12
bytes. I guess the 32-bit Windows people never read

http://www.intel.com/design/processor/manuals/248966.pdf

where it is recommended in section 3.6.3:

"Align 80-bit data so that its base address is a multiple of
sixteen."

On 2008-05-31, James Van Buskirk comcast.net> wrote:

Janne Blomqvist wrote:

Even worse, the four byte alignment for REAL*8 was used, and not
corrected for a long time. I thought by now eight byte alignment
for REAL*8 was pretty well standard. (Yes, Starting with the
pentium is was much slower than odd four byte alignment.)

James Van Buskirk comcast.net> wrote:

You're kidding, right? I suppose you probably are so used to TRANSFER
that you aren't kidding, though. :-(

Trust me that it is hard to read for lots of people. Me for one, and
I've plenty of data to suggest I'm not alone. Yes, I can figure it out,
but only by sitting down and meticulously working through it. I sure
can't just read it.

And that's for the relatively simple cases (notably ones where the size
of things match). When you get into stuff like what happens when one
side has more bits than the other, then I simply have to drag out the
standard, which is a long ways from just "reading" the code.

I haven't sat down to try to analyze what it is about TRANSFER that
makes it hard for me to read. But I don't need to analyze anything to
observe the fact that it is hard.