This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: gfc_offset question (32 vs. 64 bits)
- From: Bud Davis <bdavis9659 at comcast dot net>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>, gfortran <fortran at gcc dot gnu dot org>
- Date: Tue, 14 Dec 2004 21:13:53 -0600
- Subject: Re: gfc_offset question (32 vs. 64 bits)
- References: <200412141841.KAA06614@hpsje.cup.hp.com>
>
> Does libgfortran (or any other GCC library) offer a way to pass compiler
> option information into a library so it could be used to change the
> libraries behavior? I guess one could invent a new interface to do
> this, I was wondering if there was any existing precedence.
more message traffic:
http://gcc.gnu.org/ml/fortran/2004-06/msg00191.html
http://gcc.gnu.org/ml/fortran/2004-06/msg00192.html
people have strong opinions on what they want; and implementing a
switchable way to do them all will be an M x N kind of solution (ugly
and prone to breakage). with that said, one of the great
things about a gpl compiler is you are free to implement any
special scheme you want.
emotions / desires are strong enough on this topic that I see patches to
implement a few of them coming !
i did not understand Steven's comment about a performance hit from
making this selectable via an environment variable. Seems minor to me,
just checking to see if the record size marker is 1 or 2 32-bit words.
setenv GFC_PDP11_32_BIT_UNFORMATTED_RECORD_MARKERS 1
./user_program
would be a rather clean way to switch between the options.
personally, i am satisfied with the current functionality. if the
system supports large files, you can read them and write them. if
not, then you are limited to 32 bits.
the overall performance of unformatted I/O is very poor. try
to write a 2-GB file sometime, it takes like 3 cups of coffee :)
IMHO, this is a more critical need for gfortran than inter-operable
unformatted files...but the only other fortran I use is g77 :)
One thing that you will find when trying to implement one of these
record length encodings is you need to know how big the record is
going to be before the start marker is written. Unless I am missing
something (which is quite possible), this will require a front end
change. The other option that comes to mind would be holding the
entire record in a memory buffer, which is not very practical.
--bud