This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io
- From: Janne Blomqvist <jblomqvi at cc dot hut dot fi>
- To: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Cc: GNU GFortran <fortran at gcc dot gnu dot org>, GCC patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 19 Feb 2005 02:30:42 +0200
- Subject: Re: Fortran/PR19303 PATCH: Runtime selection of record markers for unformatted sequential io
- References: <20050218233325.GA7014@vipunen.hut.fi> <20050218235458.GA63572@troutmask.apl.washington.edu>
On Fri, Feb 18, 2005 at 03:54:58PM -0800, Steve Kargl wrote:
> On Sat, Feb 19, 2005 at 01:33:25AM +0200, Janne Blomqvist wrote:
> >
> > - Although the code is structured so that each unit may use a
> > different record marker format, currently the only way to change the
> > format is via a magic command line switch "-frecm", whose value can be
> > either "-frecm=g77" or "-frecm=hp" (the default format cannot be set
> > with this switch and is the same format as gfortran previously
> > used). It would be relatively straightforward to add an intrinsic to
> > change the default record marker type for new units, or maybe
> > implement it as an extra option to the OPEN statement.
> >
>
> Janne,
>
> This looks like a very useful option, particularly if one can
> move access='direct' files between 32- and 64-bit machines and
> simply flip on an option to read/write the file.
No, the patch only touches access='sequential' files. IIRC, for
access='direct' there are no record markers at all, since the user has
to specify a fixed RECL when opening the file (i.e. libgfortran can
easily calculate where the record boundaries are). Anyway, endianness
might also be an issue.
I wanted the ability to change markers at runtime mainly so that users
could write programs that simultanously can support many formats,
e.g. conversion programs, legacy support etc.
> One question though. Why did you make this a magic option?
> From looking through the source, it seems you could modify
> lang.opt, options.c, and invoke.texi and maek this a full-fledge
> gfortran. Am I missing something that is perhpas system
> dependent?
Uh, aren't those only for the compiler itself? -frecm is for the
generated binary. E.g. usage is
% gfortran foo.f90
% ./a.out -frecm=g77
Making it a compile-time option might be a better way, but that
entails creating separate files with some function marked with
__attribute__((constructor)), and then some deep voodoo magic in the
driver to link in the correct object depending on a corresponding
compiler command-line option. Or in other words, my solution is a
quick and dirty one which is IMHO also easy to use when testing. It is
easy to replace it with something better (and document it!) once there
is a consensus that the general approach taken with my patch is
desirable.
--
Janne Blomqvist