[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