This is the mail archive of the
mailing list for the GCC project.
[Bug fortran/23815] Add -byteswapio flag
- From: "tkoenig at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Nov 2005 00:02:52 -0000
- Subject: [Bug fortran/23815] Add -byteswapio flag
- References: <firstname.lastname@example.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #17 from tkoenig at gcc dot gnu dot org 2005-11-12 00:02 -------
(In reply to comment #14)
> 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.