This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: -frecord-marker
On Tue, Jul 25, 2006 at 05:21:54PM +0100, Keith Bennett wrote:
> 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.
Which compiler vendor guarantees that a library you compile
with their compiler will work flawlessly with a competitors
compiler? First and foremost, a library generated with gfortran
needs to work with gfortran. You may use -frecord-marker in
a very safe consistent way, but you can't say how anyone
else may abuse this option. We, the gfortran developers,
need to consider all of the pros and cons, and come up with
a good technical design.
> > 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).
I understand what you want. Unfortunately, we aren't writing
"Bennett Fortran". Adrain's patch may be the Right Thing to Do.
However, someone needs to be the Devil's Advocate to look for
problems and issues with the design. The possibility of multiple
different recorder markers written into a single files needs
a solution. That solution may be to prohibit this behavior such
that the recorder marker of a pre-existing file will override
any requested conflicting marker.
> > 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,
That's because there are people like me who try to weed out
problems before a patch is committed. :)
> 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?
Personally, I think gcc has too many options and most should
be removed. That ain't going to happen.
If you (or anyone else) thinks you found a bug. Send a bug
report. It will be analyzed. If the best solution is to
remove an option, then yes, remove the option. This has
occurred in the past.
--
Steve