------- 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