F2003 features (was: Re: [Patch, fortran] PR20541 - allocatable components (TR15541))

[Steve Kargl]

On Tue, Oct 10, 2006 at 06:50:45AM +0200, Paul Thomas wrote:
> Dear All,
> 
> I have said this before and I will probably say this again; before we 
> launch into any more F200x projects, we must make a determined effort to 
> get F95 right,  Gfortran is still much too buggy in quite fundamental 
> things, as the batch of PRs that have been added in the last 48hours show.
> 
> My vote would be to scrub all extension projects (including 
> sub-modules!) and to embark on an effort to get the basics right.
> 
> I started a triage of the fortran PRs, which I now propose to complete 
> and post to the wiki.
> 

Paul,

I agree with your take on the current status (with the
one exception of the ISO C BINDING patch that Chris 
has been working on).

In fact, my recent rrspacing and spacing patch was a
"let's make it work" patch.  The inlining of these 
function is certainly faster than the library function
calls, but "fast and wrong" is probably not nearly as
useful as "slightly slower and correct".

To me, reading the various files has become quite cumbersome.
I just did a "wc -l *.[ch] | sort | more".  Perhaps, we
need to refactor the code (resolve.c is almost 7000 lines
long, trans-array.c clocks in at 5500 lines).  There is
also a startling lack of comments.  Perhaps, the first 
tack of order is spend time commenting all functions.

One thing that I intend to do after the 4.2 branch is
to kill the legacy gmp/mpfr code.  If someone is running
trunk, she'll need at least gmp-4.1.0 and mpfr-2.2.0.
I'll then audit all uses of gmp/mpfr.

The other item we (as a group) need to consider is grooming
new contributors.  I know Paul has new job obligations and 
I'll be winding down my contributions soon.  The code in
gcc/fortran contains nearly 96K LOC and libgfortran contains
90K LOC (not counting the generated/ files).  This stuff
isn't easy to wrap one's head around (ask pault :-).  I 
have no silver bullet solution to this issue.

-- 
Steve