Re: -frecord-marker

[Keith Bennett <keith at mcs dot st-and dot ac dot uk>]

On Mon, Aug 14, 2006, Adrian Umpleby wrote:
> Sorry to take so long to get back to this - just moved house and had troubles with phone line and
> getting reconnected...

No problem.

> > Sorry to bring up the subject again, but I really am interested in getting
> > this fixed. Is anyone actively working on getting the Intel method
> > working? Adrian?
> > 
> > I ask because my company have suggested that they might be willing to
> > pay me to do the work. Now, it would only be worthwhile if there was
> > a reasonable chance of the patch being accepted and the Intel marker
> > becoming the default (or at least easily turned on at *compile* time
> > so that it works in a library).
> > 
> > Obviously, I can't expect anyone to approve code that they haven't seen
> > but if such a patch was submitted and was of good enough quality, is
> > it likely to be accepted?
> 
> I'm sure I could get the Intel method working. However, as I mentioned, having done very little C
> programming, and having little experience with the gfortran source, I'm not certain it would be
> done in a way that would be accepted very quickly. Also, there are a few issues I'm not totally
> clear about at the moment (e.g. how it works with INQUIRE).
> 
> What I've done at the moment is to add the RECORD_MARKER tag to the OPEN statement so there is a
> per-unit record marker field, as you know. Then, if the tag is not present in an OPEN, it checks
> the value of -frecord-marker option during compilation, and synthetically adds the tag if
> appropriate. I can imagine doing it like this could be considered a bit too much of a hack (not to
> mention that it means at executable runtime it acts as if the tag existed in the Fortran code, so
> there's no scope for altering the runtime behaviour through an environment variable without
> affecting other OPEN statements where the tag really was specified in the Fortran code - would be
> easy enough to get around this with new string values for the tag that do the same jobs as those
> supplied in a real tag, but which are overridden by environment, but this is getting even more
> hackish...)
> 
> If you already have a more sensible way in mind to implement this (and if someone responds
> positively to your question about likely acceptance of a decent patch), then I'd say go ahead and
> do it.
> 
> Would it be useful for me to send you the patch that adds the RECORD_MARKER tag, so you can take
> it from there? Or might that just add confusion...?

Having given this a bit more thought, I've decided that whilst Intel record
markers would be nice, all that is really required is the ability to
specify 4-byte markers at compile time. If I have understood correctly,
this is exactly what your patch does so if it makes it into the mainline
then I will be happy.
If I can speed along the process of getting it accepted then I'm happy
to help out, but it sounds like a project which is easier left to one
person.
Have you had much positive feedback? Does it look like it's on the way
to being accepted?

Keith.