This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/23815] Add -byteswapio flag

------- Comment #17 from tkoenig at gcc dot gnu dot org  2005-11-12 00:02 -------
(In reply to comment #14)
> Thomas,
> I'm not in favor of environmental variables, which I think would
> also be Paul Brook's position.  It's too easy to have the variables
> set or unset at the wrong time.

In the docs, I would recommend setting them via



(setenv GFORTRAN_CONVERT_BIG_ENDIAN=3 ; progname )

> What are your plans for REAL(10), REAL(16), INTEGER(16), COMPLEX(10),
> and COMPLEX(16)?  AFAIK, the reals may have padding issues.

I don't have enough information about alignment to get
REAL(10) to work on a big-endian system.  If we use those,
we also get bitten by the 12-byte/16-byte alignment issue for
different architectures.  Does any big-endian architecture have

(In reply to comment #15)

> The environment variable approach also allows the same executable to be
> used for different scenarios. The only negative I see is if the executable
> was compiled by a different compiler (ifort, pgf95, etc.). A user might 
> expect that the behavior will change with an environment variable setting and
> then wonder why it didn't. Perhaps the same environment variable names used by
> ifort could be used by gfortran to limit this issue a bit?

Ifort uses environment variables based on unit numbers, file extensions,
and I don't know what else.  I'd hate to copy all that.  Also,I'd
rather stick to the GFORTRAN_* namespace of environment variables.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]