------- 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 GFORTRAN_CONVERT_BIG_ENDIAN=3 progname or (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 REAL(10)? (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815