[Bug fortran/23814] unformatted files from gfortran are incompatible with g77 unformatted files and solaris f95 unformatted files
kargl at gcc dot gnu dot org
gcc-bugzilla@gcc.gnu.org
Mon Sep 12 00:35:00 GMT 2005
------- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 00:35 -------
(In reply to comment #7)
>
> I realize that disagreeing with the assumptions made during the design may be
> regarded by some as "rants", but what I was attempting to do (perhaps poorly) is
> illustrate why simple decisions that might seem fairly benign can have huge
> efficiency impacts on a large population of users.
Why do you think that this was a "simple decision" in the initial design?
The world is moving to 64-bit CPUs, and a 32-bit record marker effects
performance (think about alignment issues). Bud has thought about this
problem for several months, produced a plausible patch, and then Real Life
got into his way. A fix to this problem takes time. There is no simple solution.
> If you read some of the previous comments, you'll see that some don't think it's
> an issue. It really is a problem that should take high priority.
This isn't pushback but reality. There are only a handful of
volunteers hacking on the code. What is a high priority to you
may not be very high on some hacker's lists. To me, fixing the
known bugs in modules is much higher priority than changing a
functioning portion of the compiler.
> I know Bud is going to apply a variation of the patch he wrote a
> few months ago soon and I'm happy about that. I hope there isn't
> any pushback from the rest of the developers.
I doubt that there will be pushback. Yes, we will review the code
and make suggestions. But, most of the developers will welcome Bud's
effort.
> I think the default should actually be 4 byte markers, but that's
> just my humble opinion.
I only use opteron base systems where a 64-bit marker is preferred.
>
> BTW, I think both spellings of FORTRAN (FORmula TRANslation)
> are correct actually: http://www.ibiblio.org/pub/languages/fortran/ch1-1.html
> http://www.engin.umd.umich.edu/CIS/course.des/cis400/fortran/fortran.html
> (Not that it really matters in the big scheme of things.)
Read the Standard. It very carefully uses "FORTRAN 77" to identify
specific references to ISO 1539:1980. Indeed, the passage in 1.6
says "Each Fortran International Standard since ISO 1539:1980 (informally
referred to as FORTRAN 77)". Note, "ORTRAN" actually appears in small
caps. Everywhere else the Standard carefully uses Fortran.
> I'll also post a small C program to convert to the g77 format soon as a
> temporary fix until the patch is in place.
Thanks.
> (I'm completely hammered with
> work right now, but I'll try to contribute more in the future. I've already
> sent in some code snippets on the little endian/big endian issue.)
So, you can appreciate the demands on the developers. :-)
I would love to devote several hours a week to gfortran, but
time is occupied by Real Life.
> I hope that we can all keep this professional in the future and
> respect people's time (development, trouble shooting and bug reporting)
> that they put into this to help make a better product for
> everybody.
Sorry if my comment appeared to be too strong, but your Comment #3 and
#5 appeared to be "preaching to the choir". We know there's a problem.
Bud is working on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23814
More information about the Gcc-bugs
mailing list