Data representation question

[N.M. Maclaren]

On Dec 4 2013, Bill Schmidt wrote:
>
>We recently disabled a Fortran test case (see
>http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03573.html) for PowerPC
>little endian targets.  The test uses TRANSFER to interpret a real(16)'s
>bits as an integer(16) and looks for expected values in the sign and
>part of the exponent bits.  Because of PowerPC's unique implement of
>real(16) (i.e., long double) as a pair of double-precision values, these
>bits are not in the expected position for little endian.  (Rather than
>being at the little-endian beginning of the entire 128-bit space, they
>are at the little-endian beginning of the first 64 bits.)
>
>Since none of us here are really knowledgeable about Fortran, this is
>just a follow-up query to see whether we should expect any problems from
>this different choice of representation.  It seems clear that the use of
>TRANSFER is extremely target-dependent, and that code making assumptions
>about bit representations when using TRANSFER should expect some porting
>problems.  (Similarly with using EQUIVALENCE, COMMON, etc. to obtain the
>same effect as C unions.)  However, our little-endian long double may be
>considered more surprising than usual, in that even the sign bits of
>integer(16) and real(16) are not in the same place.

It's not all that unusual, actually :-)  As Tobias Burnus said, Fortran
distinguishes between portable and non-portable constructs pretty
strongly, and the former are designed to work on a far wider range of
architectures than exist today.  As you point out, TRANSFER is in the
non-portable category and its behaviour is entirely dependent on the
compiler.  You have named the main places where the representation is
exposed - there may be a few others, but they will be fairly well
isolated.

Now, that's strictly a Fortran standard answer, not a gfortran one, but
gfortran is pretty clean.

Daniel Chen is currently IBM's representative on SC22WG5, incidentally.


Regards,
Nick Maclaren.