-frecord-marker

[Keith Bennett]

On Tue, Jul 25, 2006, Steve Kargl wrote:
> Bingo.  We have a winner!
> 
> Developer A compiles his library with Intel markers because
> everyone uses Intel markers.  Developer B gets a copy of the
> library and uses 64-bit markers.  Developer B can't figure
> out why gfortran produces corrupt files.

This is exactly what happens currently when mixing gfortran
and any other compiler. One of the problems that it would be
nice to have at least a partial solution to.

> You failed to answer the questions.
> 
> 1) Do we mingle different markers in a single file?

No. I'm sure there are people out there that want it, and if it
was possible to implement in a sane manner then I'd have no real
issue with that, but I personally don't have a use for such a thing.

> 2) Do we detect that different markers would be written to
>    a file, and to the conversion of markers by rewriting
>    the file?
> 
>    Your TB file objection seems to nullify this option.

Again, not something that I am calling for personally. I just want to
be able to specify a marker at compile time that is compatible with
that of the file that I'm going to read in. Something that can be
accomplished already by using the -frecord-marker provided that your
main routine is fortran. I'd just like to be able to do the same thing
when fortran isn't the main routine. (eg. a fortran library being called
from within a C program).

> 3) Do we issue a runtime error and abort?
> 
>    Aborting a program that's run for several days due to
>    inconsistent markers would probably annoy the user.

Programs already behave incorrectly if you are trying to read a file
with a different record marker. The only real difference is at the
moment that means pretty much *any* file not generated by gfortran.

Now, I agree that a single record-marker format would make things simpler
for the end-user. I wouldn't mind a single format, provided it was one
that was interoperable with other compilers. The Intel one would be fine.
>From what I've read, the HP one is also acceptable.
I don't think that this is very likely, though. So if the default marker
is going to remain incompatible with other compilers, there at least needs
to be some method of changing it at compile time.

> I've read comp.lang.fortran and this forum long enough to
> know that if you give users a loaded gun, they will shoot
> their foot.
> 
> > I would never have expected it to work in the first place. I'm
> > sure that there are plenty of things that can be done using
> > existing compilation options that cause all hell
> > to break loose. That's no justification for removing them.
> 
> It would be called a 'bug'.  After a bug report is filed,
> we would try to fix it.

Well, I can't think of any gfortran examples off the top of my head,
but gcc has the option of changing function-calling conventions. That
can certainly leave you with unusable binaries if used incorrectly.
Would you say that it was a bug and should be removed?

> > Conversion just isn't a practical solution.
> > 
> 
> The conversion is done once.  Disks and cpus are fast.

You obviously aren't using the same shared resources with all its
associated quotas as I am. On those machines disk is most certainly not
cheap. I'm glad you have the resources to cope.

Besides that, I don't relish the idea of telling customers that since
we started compiling their libraries using gfortran they will now have
to convert all their data whenever they use our routines.

Keith.