[Top] [Contents] [Index] [ ? ]

Why I'm Stopping My G77 Work


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Why I'm Stopping My G77 Work

Early in 1999, I notified the EGCS Steering Committee (now GCC Steering Committee — see http://gcc.gnu.org/) that I intended to cease my role as de facto g77 project leader.

At that point in time, I'd hoped we (including myself, a member of the Steering Committee at that time) could come up with a plan that involved a person or group taking over as g77 project leader, thus allowing me to focus on improving g77 mainly via bug-fix, code, and documentation improvements, as well as my suggestions for how best to improve it.

The discussion at that time culminated in a decision to attempt to seek general direction from that portion of the Fortran community interested in g77 (not just those currently using it, but those who'd like to use it someday) by inviting the public to a meeting for that very purpose.

This became the GNU Fortran BOF. I personally found that meeting, run by Toon Moene, very enjoyable, as it gave me an opportunity to meet the most g77 people I'd ever met in a single place.

We decided I should start the long-awaited rewrite, and, when I returned, I initially got off to a good start, before pausing to take care of various things (such as upgrading my systems, dealing with the GCC 2.95 release, and so on).

However, pretty much all the assumptions upon which I'd confidently predicted I could accomplish — design, implement, test, and release—the rewrite in time for a GCC 3.0 release have since been dashed.

The result is that I don't believe it is likely I'd be able (or allowed) to release the rewrite, as I currently envision it, in GCC 3.0, and, even if that was possible, the rest of g77 would likely be in such poor shape that the rewrite would be initially seen by users of GCC 3.0 as, at best, a fairly big waste of time and, at worst, the end of g77 being seen as an adequately stable, reliable compiler.

The main reasons I've decided to stop working on g77 are:

Lack of Interest
It's been apparent to me for some time that the level of interest in ongoing improvements to g77 is quite low, compared to other projects to which I'd be able to contribute.

Adequacy
I've been told (by fairly reliable sources) that g77 is seen by many of its users as sufficiently usable and stable for their needs.

This probably explains some of the perceived lack of interest in the face of what strikes me as a substantial "Internet presence" of people who seem interested in g77.

Quality of End Result
Even if I worked 80 hours a week for the next two years straight, I don't believe I could deliver a g77 which I'd, personally, consider to be of a level of quality more than merely adequate for a small, specific audience.

Time and Effort
I've already put in far more time and effort trying to finish g77 than I ever imagined I would, back when I first undertook this project.

Uncertainty
While working on g77, I feel my degree of understanding of what the Fortran community wanted from a compiler product, which started out pretty low anyway, has declined to the point where I really have no idea what it wants. And when I ask simple questions in various forums, the answers are usually highly contradictory.

Controversy
My own vision and understanding regarding where the future of Fortran should lie — at least in those areas where I believe I now possess sufficient expertise and experience to make decisions — is not sufficient to realize a complete Fortran product line.

And, too many times, when I've suggested a course of action, or even highlighted the unfortunate effects of past decisions (decisions that contradicted my understanding of certain aspects of product development), substantial controversy has ensued, often involving people upon whom I've relied in the past to make g77 as good as it is, who generally do not (or no longer) see me as sufficiently capable of continuing in my role as de facto g77 project leader.

The implication is that it's highly unlikely I'd be able to succeed in any of several possible roles I'd considered for myself to continue improving g77.

The GCC Project
Formerly referred to as EGCS, GCC is now in the hands of a group of developers with, in my opinion, an awful lot "on the ball". Not that we always agree with each other, but there is so much that is positive about the way GCC development is run, that I believe it's possible g77 might survive, perhaps even flourish, as "just another GCC front end", even, perhaps especially, without my making substantial contributions to it.

My Future
I intend to limit my g77 work to very-part-time work that only I can do, because I have other things I want to work on, and I believe I'll do a better job at them in the long run.

These items are expanded upon below.

If you have comments on this document, email me at why at-sign jcb-sc.com. It's definitely a "living" document!

The comments I've received since publishing this document (on 1999-09-01) suggest that adequacy best describes the current situation, short of offering Fortran 90 or beyond.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.1 Lack of Interest

First, I was quite delighted, and a bit surprised, at how many people at LinuxExpo stopped myself, my wife, or Toon Moene (wearing our GNU Fortran T-shirts!).

However, the fact remains that, based on funding I've received over the past 18 months or so —a single donation! — it's impossible to come to any practical conclusion other than that there simply isn't much interest in further improvements being made to g77 as such.

(There might be interest in improving its optimization abilities, but not by sending donations to me to do it — which makes sense, since I've generally avoided the strong temptation to get involved in the optimization phases of g77, which are shared with gcc, g++, and so on. There's already a reasonable track record of such improvements being made with little help from me.)

Of course, I'm very grateful for the funding I have received to date.

And, I've certainly gotten plenty of help from people in the form of suggesting how I could make it easier for people to donate to my g77 work.

But, these suggestions almost always revolve around me doing more work, like making a fancier web page, setting up a credit-card account, researching various up-and-coming methods for funding free-software developers, and so on.

Frankly, none of that is my job, nor is it necessary for me to undertake it.

If people want to donate to g77, it's quite trivial for them to do so, and they can't possibly miss how to do it if they devote even 1% of the time I'd have to devote to "make it easier for everyone".

Further, anyone can take the same steps that have been suggested to me to take, serve as a collection point for my work, and forward me the monies as donations.

Since nobody has done that in the years I've worked on g77, I think it's reasonable to conclude there simply isn't much interest in that sort of collection-point work.

I've actually come quite close, several times over the past years, to deciding to go into what would essentially be a fund-raising occupation vis-a-vis g77. Each time I decided against it, it was due to the above reasoning. The unique contribution I have to make has never been my fund-raising abilities, my leveraging of new technologies like the WWW, and so on.

Even if I was an expert in fund-raising, even if I started up the best g77 (or g90) fund-raising campaign imaginable, it's not clear to me I'd have been able to actually raise enough interest in providing actual funding, sufficient to, first of all, make up for the fact that I was no longer actually working on g77 itself.

And, if there was so much interest, why not let someone who is interested and understands fund-raising take the lead?

There's nothing preventing that from happening now. Maybe there'll be more incentive to do it, now that I've stepped aside.

One interesting, and recent, development has been the arrival of several organizations trying to address the apparent need to connect free-software developers to free-software funders to free-software users, with the idea of making funding happen in a way that is about as open as open-source development itself.

For example, in July I checked out http://www.cosource.com/, and found two proposals for improving g77.

Though these didn't seem to have any funding as yet, this site is at a very early stage in its life as of this writing, and there are other, similar sites, as well.

While it is possible this might lead to my doing g77 work for direct funding (possibly bidding on proposals), it's also possible other developers might take on the work!


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.2 Adequacy

The perceived adequacy of g77 for many tasks, perhaps relating mostly to compiling legacy code, probably explains some of the perceived lack of interest, described above.

It's partly due to feeling there are plenty of satisfied g77 users out there that I don't think it wise to introduce risks by rewriting a relatively stable, key component of it, and question the value of trying to improve it substantially without being sure the end result would be of sufficient quality to attract a large number of new users (both addressed below).

Since first publishing this document, I've gotten a few emails from g77 users apparently confirming that it is adequate for many uses.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.3 Quality of End Result

Over the past few weeks, while the rewrite itself was on hold, I've been thinking about the state of various components, or aspects, of g77:

The Parser
(Or, the real "front end" of g77, the part of it that doesn't really do much about code generation.)

This is the part that I was rewriting, nearly from scratch, for the GCC 3.0 (g77 0.6) release.

It's long been known to have several design failings, some of which result in actual bugs (involving things like cross-compilation), most of which make it hard to add important features and improve diagnostics.

The Code Emitter
This is the part of the g77 front end that converts the parsed Fortran code to the representation the GCC back end (GBE) understands.

In a sense, this is a code generator, but not in the context of GCC itself.

This component has nearly always undergone lots of change from release to release, as it probably gets the most bugs report of the major g77-specific components.

The Run-time Library
libg2c, the g77 variant of Netlib's libf2c, differs from libf2c so as to make automatic building within the context of GCC possible.

It also differs from libf2c in ways that seemed perfectly reasonable and supportable back when we introduced them, but have since, at least on occasion, caused new bugs to be introduced by simply merging in changes to libf2c.

This component also seems to get lots of bug reports. The more it diverges from libf2c, the less sure we are as to whether the bugs are in libf2c, libg2c, or elsewhere. We (the g77 developers) definitely aren't libf2c experts.

(We've had much more success maintaining the libU77 component of libg2c, which is unique to g77. It doesn't have anywhere near the complicated interactions of the libI77 component, and was written in pretty straightforward C code. We've done okay coping with the libF77 component as well, mainly because it has few interactions among its entry points.)

The Code Generator
This is the code base g77 shares with gcc, g++, and so on.

In the past, we got lots of bug reports that seemed to be against this part of g77, and often couldn't do much about that.

The EGCS, now GCC, project has pretty much changed all that. Especially for ICEs, or Internal Compiler Errors, even GCC developers who aren't Fortran enthusiasts often are willing and able to track down and fix bugs exposed only, or primarily, by g77.

Many performance improvements for g77 are best made here. Some of them require improvements to the front end. For example, the front end could pass more information to the back end, allowing the back end to do some more optimizations.

The Math and System Libraries
libg2c depends mightily on underlying math and system functions, mostly in libm and libc.

While libc tends to work pretty well on a given system, we've had various reports of problems in the libm for a system here or there.

Also, there are opportunities for performance improvements here. For example, the big performance advantage of Digital Fortran over g77 on Alpha computers had, reportedly, a substantial chunk taken out of it by using new libm routines written just for that purpose.

The Test Suite
The g77 test suite is pitifully inadequate.

This was driven home in particular during the GCC 2.95 release cycle, when a variety of "last-minute" bugs were found, pretty much all of which should have been found weeks or months earlier.

Part of the solution is that I, personally, have a much larger test suite resulting almost entirely from test cases emailed to me over the years.

However, until a few years ago, I didn't keep track of who sent me which test cases (though I have email archives I can search by hand), so the copyright status of any given test case is not trivially determined.

Further, I didn't automate this personal test suite beyond having the f771 (Fortran-to-assembler) module run over it, there is no automated index regarding which tests constitute executable programs, which need data files, which should be compilable, which should produce diagnostics, and so on.

Some of this information could be culled, at least initially, from the "golden" files in my test suite, but, in any case, submitting one of my personal tests for use in the g77 test suite (as shipped with GCC) is not a trivial task. It can take from 5 minutes to an hour or so to do the requisite research, which could then require contacting the original submittor to obtain permission to include the test in the test suite.

In the meantime, the test suite could be improved by others as well, and has been, on an ad-hoc basis, in the past. Coverage is known to be bad — a recent bug that made the NINT intrinsic return bad results on certain Alphas turned out to be a code-generator bug, but would have been easily caught much earlier (in plenty of time for 2.95) had simple coverage tests for the intrinsics been written. That's something nearly anybody modestly experienced with Fortran can do.

The Documentation
Most of the problems with the g77 documentation seem to stem from people not reading it.

Still, it could use improving, especially in the form of a complete language reference manual for the GNU Fortran language.

However, some of what most needs to be documented for g77 users involves components outside of g77 itself, such as GCC, shared libraries, and so on. At the very least, cross-references from the g77 documentation to other, existing, documentation should be added by someone who can take the time to research the topics and find where they're already well-documented.

Note that GCC's document set is likely to be reorganized in the near future. I think g77's document architecture is in pretty good shape vis-a-vis any reasonable new organization, and perhaps even includes some unique features that could serve as models for the new organization.

The Specification
What should the GNU Fortran language be? What "promises" should be made about how g77 behaves?

The Fortran standards (especially ANSI FORTRAN 77, upon which g77 is largely based) say very little about certain things, such as how floating-point computations and approximations are done.

Seemingly simple issues, such as whether g77 should provide referential transparency (whether, after a statement like `A = B * C', it is guaranteed that all references to the value stored in `A' obtain the exact same value — a property that is not provided by g77 at the present time, due to GCC not spilling 80-bit temporaries to 80-bit stack slots), turn out to stir up huge controversies when raised.

Without a fairly clear specification, or design, as to what g77 is supposed to do, developing it can involve ping-ponging back and forth between camps of users, who want different things, sometimes consisting of the same people in different moods!

The Debugger
g77's problems with debugging are widely recognized. Though most of them probably require changes mostly to g77, some of them require some devoted work on gdb.

And many of the features people want added to g77 will require work on gdb to properly round out the Fortran debugging environment.

Taking all the above into account, it has become clear to me that the highest-priority three or four items that need to be addressed to improve g77 do not include the parser.

In particular, it is now my assessment, as a (de facto, anyway) product architect/designer, that rewriting what amounts to the most stable of the g77-specific components, without some of the other components (especially the test suite) having first been significantly improved, would likely make g77 substantially worse, unless it was magically done perfectly.

I may think pretty highly of myself, but I don't think I can do the rewrite "perfectly", by my own standards, and especially not by the sometimes-arbitrary, and certainly contradictory, standards of the audience for the rewrite.

For example, without some pretty clear specifications to point to, as having been previously agreed upon, it will be difficult or even impossible to convince substantial numbers of g77 that even a "perfectly executed" rewrite is correct. (This is addressed further below---see section 1.6 Controversy.)


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.4 Time and Effort

I've already put about eight more years, much of it nearly full-time, into working on g77 than I'd imagined from the start.

Now seems like a good time to finally move on.

Further, the effort needed to really "finish" g77 substantially on my own (even just working on the front end and run-time library) is well beyond my ability to execute in any reasonable time-frame.

The GCC project has offered, for some time now, a much more direct means for people wishing to offer substantial help, but, for whatever reasons, this has not been done so far.

Some reasons for this might include my own self being "in the way", in both good ways and bad, but we won't really know whether that's the case as long as I continue to "hold the fort" myself. (Recent history—between September 1999 and April 2000 — suggests that wasn't the problem after all. While it might be good news that I wasn't standing in someone else's way, it's bad news that someone else hasn't stepped forward, now that I'm out of the way, and taken the reigns of g77.)

Also, it's not unreasonable to consider the possibility that g77, even if an ideally finished product, is no longer of much value to the Fortran community, which may well consider Fortran 95 to be a minimum level of compliance.

And, there's no way I can do Fortran 95 by myself. I could project-lead a well-funded effort, perhaps, but I'm interested in such an effort only if it is directed towards providing a complete, high-quality, high-performance product in a useful timeframe (within three to five years, depending on whether Fortran 2000, or whatever it'll be called, is included in the list of requirements).

Funding for that sort of effort would run well into the millions of dollars at first glance, perhaps tens of millions upon thorough analysis.

Note that, since this document was written in September 1999, a GNU Fortran 95 project has been started. See http://g95.sourceforge.net/.

To meet my definition of high-quality vis-a-vis a Fortran compiler, it'd have to include a completely new code generator as well as new run-time libraries. I.e. no using much of anything currently in GCC. (The new project seems to assume the need for new libraries, but not for a new code generator. I hope it'll prove me wrong, because leveraging GCC would save huge amounts of time and effort.)

At least, based on what I've seen, the current products simply aren't architected for the high standards of quality, robustness, and maintainability I believe will be considered required for products like a Fortran compiler circa the year 2005. Other reasons for starting from scratch including designing into the system concepts like automatic parallelization, automatic serialization, integrated debugging from source all the way down through compiler transformations to the machine code, and so on. (It's difficult to assess the new G95 project vis-a-vis these concerns at this time — the project is in very early stages.)

In the end, I've concluded my time and energy is better spent, in the future, on projects for which I personally have a strong need (I'm not a Fortran programmer, nor do I use g77 to compile other peoples' code) and/or for which I have reason to believe will be a huge success, in one way or another.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.5 Uncertainty

In my role as g77 project leader, I've had to not only make decisions as to what is the best direction for the project, I've often had to do much of the research and "creative" aspects of determining what possible directions to take.

I'm reasonably creative, in terms of thinking about different ways to approach a problem or a new opportunity, and I'm pretty good about carefully thinking through the implications of each different way.

But, I'm not particularly good about doing the research that's appropriate for a project like a Fortran compiler. Mainly, that's because I'm not funded sufficiently to do things like buy and evaluate other Fortran compilers, though it's also because I don't have particularly good research habits.

Personal failings aside, even if I had great confidence in my research abilities, there'd still be the problem of understanding what the Fortran community wants.

Many years ago, I had been working in what amounted to a Fortran vendor (for the most part) long enough to be aware that I'd learned a lot about the Fortran community.

I believe that knowledge is "stale" at this point. None of my major contracts since leaving that vendor have involved Fortran, or even numeric/scientific computing generally.

Further, I'm aware of at least a few "camps" of Fortran users, with divergent views on controversial issues that go to the heart of how a Fortran product should be designed. Just asking questions in comp.lang.fortran often isn't sufficient to get a clear answer to some of these questions, given the existence of these camps. The same goes for issues raised on the GCC mailing lists.

I've been tempted to believe I could just forge ahead, with at least some confidence in my ability to make the right decisions more often than not, but, while that might work in some other area, my confidence in my ability to do that within the Fortran community has severely dropped over the past year.

So, it's likely I'd do more harm than good by forging ahead on my own. The result would be a product few people willingly use, or one over which too many arguments (there have already been too many, frankly) take place regarding how to change my designs out from under me.

(I can't think of a good way to explain the distinction between people improving code that I write, which I do want, and people changing its fundamental nature, which I don't, at least not within the context of the official product. An example, though, is that if I put a lot of effort into implementation-defined behavior that depends on predictable floating-point behavior for usefulness, I don't want people reducing the predictability of behavior just to achieve better performance by default, since that makes the other choices I made not only wasteful, but perhaps highly misleading and bug-inducing.)

What I feel is certain is that the people who want performance at the expense of robustness and reliability should have the opportunity to learn, for themselves, what the results of that pursuit are. One way for them to learn that is to take over g77. (I, too, used to think compiler people were unnecessarily worried about robustness, clean and simple designs, etc., when I, as a programmer, just wanted fast code. Then I became a compiler person....)

In any case, it seems clear to me that I'm now far less sure I know what I'm doing as g77 project leader than are many others who have strongly disagreed with my recommendations in the past. If I'm wrong in how I approach things, as is likely the case, g77 would unquestionably benefit from their leadership. If I'm right, their leadership will give them (or, at least, others, by watching what happens) the opportunity to discover and learn from that.

And, ultimately, I'm much more interested in people (especially myself) learning to value robustness, reliability, predictability, and true simplicity of design, than I am in making only g77 a better product.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.6 Controversy

Even during that period when I was highly enthusiastic about the prospects of re-designing and re-implementing most of the g77 front end, I entertained many doubts about the likely outcomes of several of the design decisions I was making. I felt they were likely, down the road, to be considered "terminally controversial" by at least some people, though I figured I'd at least have the support of the rest of the "core developers" of g77.

Since then, it has, for various reasons, hit home with me how little support I really have for the sorts of decisions I make, and opinions I express, regularly, usually out of necessity, or at least out of a desire to not have someone ask me, years from now, a question like "well, why didn't you warn us about this decision before we committed to it, if you knew it was wrong back then?".

Still, I have received quite a few expressions of support in recent months, though mostly from people from whom I can't recalling hearing before.

This suggests the existence of a large community out there that is interested in the sort of g77 I'd like to create. But perhaps these are just people who happen to agree with my reasoning, not who are interested (or prepared to fund, or help improve) g77 per se.

In the meantime, it doesn't seem wise to take a risk that, by probably alienating my current g77 supporters even further, I'd somehow uncover a whole new source of support (and funding).

If I'm going to take a risk like that, the payoff might as well be software I can use — that way, if nobody else likes it or wants to help improve it, at least it's still useful to me (or I've learned some more good lessons)!

One project I've watched much of this year is qmail. This has really woken me up to the importance of having "core supporters" who will "go to bat" for the developer(s).

When I consider how much better a programmer Dan Bernstein (the author of qmail) is than me; the fact that many of the required activities of a Mail Transfer Agent (MTA) are clearly spelled out in RFCs, compared to the relative lack of specification of how a Fortran compiler should do floating-point arithmetic, for example; the fact that a compiler is generally a vastly more inherently complex beast than an MTA (though you wouldn't know it by looking at sendmail); the large amount of controversy over what seem, to me, like slam-dunk-correct decisions by Dan in his implementation of a robust, bare-bones (yes, they are related!) MTA; the fact that qmail cannot be redistributed without changes approved by Dan, unlike g77 or other GNU software; it is clear to me that, without (deserving?) the support of some core developers/users to prevent "consensus" opinions from resulting in quick, wrong-headed decisions to "fix" g77, my efforts to make it robust, clean, bare-bones, etc., will be wasted.

Yet, if I don't worry about making it robust, clean, and bare-bones, it'll take vastly longer to rewrite, and be much harder to maintain (as it already is) in the long run.

For example, I've already decided the lexer should read just two kinds of source file, which I'd like to dub GNU Fortran fixed and free forms, and all other kinds (which includes anything using column 73 and beyond as implicit commentary) will require preprocessing.

As soon as I realized that was the correct decision, back in May or so, I also realized there'd probably be constant pressure to "fix" g77 so "legacy" code (using column 73 and beyond as implicit commentary, using TAB as something other than the equivalent spaces, whatever) is compiled "faster", even if that means complicating the lexer.

When I realized I didn't have the equivalent of a Russ Nelson backing me up (not that I necessarily deserve one), it became clear that, while this particular issue might not work out as badly as I imagined it might, there'd be plenty of other opportunities for my designs to be deemed too controversial and thus "fixed".

That wouldn't bother me so much if I had lots more confidence that I could make g77 so good it'd literally scare people into not wanting to go against my recommendations, whatever they might be, or if I had so little confidence in my design abilities that I looked forward to my designs being fixed by others.

But, in the latter case, I've learned things about product design that too many others, active in free-software development, are wilfully blind to.

They will happily ignore my pointing out that duct tape is not to be used to attach a wing to a passenger airplane, because they're experts on the use of duct tape, or they might ask me how dare I comment on their designs, as I'm not an expert in aircraft design. Then they will go on trying to get their pet changes made, changes which almost always make the product (whether it's g77, GCC, or whatever) more complicated, less predictable, less standard-conforming, and so on.

I'd much rather be a small fish in a big (or any) project, with the bigger fish representing, to me, people with more understanding of quality product design, than the big "guru" fish in a small pond. I simply have too much to learn about how to do things right, even though I'm confident I know whether to say something is being done wrong.

So it's not so much that I'm wanting to avoid controversy. I'm just getting little out of it these days. My professional career, early on, consisted of controversy where, while indeed I did turn out to be "right" in some cases, I usually learned a lot (or at least learned about stuff I didn't know) by disagreeing with my (technical) superiors. I miss that. And the technical superiors I'm aware of today, from whom I'd like to learn (at least by more closely examining their writings and products) aren't working on g77.

The kind of controversy that'd benefit g77 would be that which gives its developers, as well as its users and supporters, opportunities to learn more about creating a great product. I don't think my stepping aside will reduce those opportunities — I think it might even increase them.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.7 The GCC Project

My history vis-a-vis g77 has been largely associated with the "cathedral" model of pre-EGCS GCC, though, in practice, it was even more cathedral-like than GCC ever was. (At least partly due to the fact that a far lower percentage of Fortran programmers think of themselves as potential compiler hackers compared to the percentage of C programmers who do.)

EGCS, now official GCC, is much more "bazaar"-like, but I haven't really made the changes necessary to allow the g77 component to truly benefit from that environment.

The rewrite was intended to make a big dent in making g77 as easy for people to improve and fix as other components of gcc.

But the rewrite really should be implemented, if not designed and perhaps even specified and architected, using the "bazaar" model as well. That would greatly improve its chances of many people being willing to continue improving it, compared to my doing the bulk of the work up-front using the cathedral model and then foisting the results off on "mere programmers" to maintain.

The new GCC environment is a great one in which to work. Even GCC developers not normally interested in Fortran have (in most cases) enthusiastically offered advice, counsel, bug-fixing, and so on.

I think that if and when the new g77 leadership deemed it appropriate to undertake a rewrite of the sort I'd long planned, there might be a great deal more interest (and willing hands) than I'd have found by doing it myself this year, as a result of (necessarily) opening up development, even at the risk of making some missteps in the short term.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1.8 My Future

My future is not likely to include any work on g77 or GCC. If I do volunteer work on a code generator, it'll probably be one that has correctness as, by far, the #1 priority, by building it into the architecture and design of the product.


[Top] [Contents] [Index] [ ? ]

Table of Contents


[Top] [Contents] [Index] [ ? ]

Short Table of Contents

1. Why I'm Stopping My G77 Work

[Top] [Contents] [Index] [ ? ]

About this document

This document was generated by James Craig Burley on November, 6 2001 using texi2html

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[ < ] Back previous section in reading order 1.2.2
[ > ] Forward next section in reading order 1.2.4
[ << ] FastBack previous or up-and-previous section 1.1
[ Up ] Up up section 1.2
[ >> ] FastForward next or up-and-next section 1.3
[Top] Top cover (top) of document  
[Contents] Contents table of contents  
[Index] Index concept index  
[ ? ] About this page  

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:

This document was generated by James Craig Burley on November, 6 2001 using texi2html.

C -----------------------------------------------------------------------
C                   ----- GNU Fortran (g77) -----
C -----------------------------------------------------------------------
C
      PROGRAM G77
C
      COMMON/QUICKY/QNEWS,QWHAT,QWHO,QHOW,QWHERE,QRLEAS,QSTAT,QWANT,
     1  QY2K,QALIGN,QFUND,QF2C,QMAIL
C
      REAL BOF
C
      WHAT() = 2. * 3.14 * QWHAT
C
      READ *,STATUS,NEXT
      CALL GIMME(FUNDS,*999)
      PRINT *,'Goodies For Contributors!!'
      GO TO (999),NEXT
      CONTINUE
      INQUIRE (UNIT=99,NAME=WANTED)
      CALL WHO(CRUNCH)
999   STOP 3HWHY
      END
C
C -----------------------------------------------------------------------
C
C Copyright (C) 2001 James Craig Burley
C
C Last modified 2007-06-09
C
C -----------------------------------------------------------------------