Updates to gfortran.texi "Project Status" section?

[Paul Thomas]

Brooks,

> The "Project Status" section of the manual seems to be painfully out 
> of date, compared to my impression of the current status.  I'd like to 
> offer an update for it, but I'd like to get some consensus on what the 
> current status actually _is_ before doing so.  What follows are my 
> comments and suggestions, interspersed with quotations of the existing 
> text.  I'd appreciate opinions and discussion.
>
Wonderful!

> Also, are there meta-bugs (other than the #19292 "g77 features not yet 
> implemented" one) or such that I should look at for data for this?  I 
> presume that the "status" pages off http://gcc.gnu.org/fortran/ are 
> considerably more out-of-date than the 2006/06/21 "last updated" note 
> would indicate, since one of them says "we hope to include a beta 
> version in GCC 4.0"....

Fortran meta-bugs:
19276   CHARACTER related bugs in gfortran                      3 
remaining out of 53
19292  g77 features lacking in gfortran                                  
11 remaining out of 105
20585 Fortran 2003 support                                         
          11 remaining out of 18
23262 [mingw32] gfortran testsuite bugs                                  
1 remaining out of 5
24546 gfortran debugging problems                                       
10 remaining out of 10
27766 -fbounds-check related 
bugs                                           1 remaining out of 10

I think that there are some missing from 20585 and 24546; I'll try to do 
a count.

>
> At this point, I'd say, "Gfortran is currently able to compile 
> real-world programs.  However, it is still under development and has a 
> few rough edges."
>
> It may be useful to expand some of that into explicit mention of 
> "nearly all standard-compliant Fortran 95 programs and many legacy 
> Fortran programs, including a number of non-standard extensions."  I 
> might also include some examples of known large codes that compile 
> with Gfortran.

Yes indeed; including Toon's, tonto, the Polyhedron tests etc., etc.

>
> For that matter, http://gcc.gnu.org/wiki/GFortranResults lists the 
> NIST F77 testsuite and the LAPACK testsuite, both of which seem worth 
> mentioning (though do we have a more current result for LAPACK?).  Are 
> there other significant ones?  Should I list successful execution of 
> the Polyhedron benchmarks, and mention "respectable performance" on them?

The "respectable performance" is something that we can be proud of and 
we should be setting our eyes on improving it.   However, the Polyhedron 
diagnostic tests are indicative that we still have a way to go to 
compete with the best commercial compilers.

>
> My understanding is that Gfortran currently implements the entirety of 
> the Fortran 95 language (but not including TRs), which means that it 
> will compile nearly all standard Fortran 77 programs as well.  In 
> addition, it supports the majority of g77 functionality at this point. 
> Yes/no/opinions?

The only F95 feature that I know of that it doesn't do is that of 
pointers to components of derived type arrays:

  type :: mytype
    real :: a
    integer :: b
  end type
  type (mytype), target :: c(10)
  integer, pointer :: d(:)
  c%b = 42
  d => c%b
  print *, d
end

compiles but does not run correctly.

A very minor point is that array TRANSFER does not work in 
initialization expressions (PR18769).  Steve and I have discussed how to 
fix it and it is assigned to me.... Soon, I promise!

>
> What about large common extensions?  I would think that the Cray 
> pointers deserve a mention here.  Anything else?  Stream I/O from F2003?
>
>> @menu
>> * Compiler Status::
>> * Library Status::
>> * Proposed Extensions::
>> @end menu
>>
>> @node Compiler Status
>> @section Compiler Status
>>
>> @table @emph
>> @item Front end
>> This is the part of gfortran which parses a source file, verifies 
>> that it
>> is valid Fortran 95, performs compile time replacement of constants
>> (PARAMETER variables) and reads and generate module files. This is
>> almost complete. Every Fortran 95 source should be accepted, and most
>> none-Fortran 95 source should be rejected. If you find a source file 
>> where
>> this is not true, please tell us. You can use the -fsyntax-only 
>> switch to
>> make gfortran quit after running the front end, effectively reducing 
>> it to
>> a syntax checker.
>
>
> This is still true, I believe.  Though I think that the "most 
> non-Fortran-95 source should be rejected" really should be restricted 
> to _diagnosably_ non-standard code; there are plenty of ways to write 
> illegal code that no compiler will catch.

We should still be going like crazy after ICEs on invalid code.  They 
are indicative of non-standard code that could be diagnosed.

>
>> @item Middle end interface
>> These are the parts of gfortran that take the parse tree generated by 
>> the
>> front end and translate it to the GENERIC form required by the GCC back
>> end. Work is ongoing in these parts of gfortran, but a large part has
>> already been completed.
>> @end table
>
>
> As I understand it, this work is effectively complete, and there is 
> nothing that the front end will parse that can't be delivered to the 
> middle end, yes?

Ooohhh; having just added arbitrary derived type components to derived 
type constructors, which was parsed but not dealt with, I am not sure.  
There are still a number of ICEs in trans-xxx.c that might be 
attributable to this but the majority are front-end problems, I think.

>
> Given this, I'm of the opinion that the distinction between the 
> front-end and middle-end-interface status here is obsolete, and the 
> above two sections should be collapsed into "Compiler Status" or 
> something like that.

I would agree with that - as far as somebody wanting to find out about 
gfortran is concerned, the distinction is likely to be incomprehensible.

>
>
>> @node Library Status
>> @section Library Status
>>
>> Some intrinsic functions map directly to library functions, and in most
>> cases the name of the library function used depends on the type of the
>> arguments.  For some intrinsics we generate inline code, and for others,
>> such as sin, cos and sqrt, we rely on the backend to use special
>> instructions in the floating point unit of the CPU if available, or to
>> fall back to a call to libm if these are not available.
>
>
> Still true?  Though this is more "design" than "status" information.
>
>> Implementation of some non-elemental intrinsic functions (eg. 
>> DOT_PRODUCT,
>> AVERAGE) is not yet optimal. This is hard because we have to make 
>> decisions
>> whether to use inline code (good for small arrays as no function call
>> overhead occurs) or generate function calls (good for large arrays as it
>> allows use of hand-optimized assembly routines, SIMD instructions, etc.)
>
>
> This seems true but nearly tautological.  Are we still in a _notably_ 
> non-optimal state with regards to these intrinsics?  If so, are there 
> particular ones that should be noted here?

DOT_PRODUCT is fixed and is one of the reasons for the passable 
Polyhedron performance; MOD is one that niggles at me (PR24518) and I 
suspect that we have some problems with 64 bit library functions (for 
AMD-64 anyway).  Evidence for the latter comes from the Polyhedron 
tests.  With 32 bit machines Intel and gfortran are neck and neck; 4 or 
5 tests separate out on 64 bit machines.

>
>> The IO library is in a mostly usable state.  Unformatted I/O for
>> @code{REAL(KIND=10)} variables is currently not recommended.
>
>
> Still true?  (And that caveat ought include REAL=16 variables too, 
> right?)  Can I say something stronger than "mostly usable" here?  (In 
> particular, is it effectively complete except for the large reals?)
>
>> Array intrinsics mostly work.
>
>
> Is this still a "mostly", or is this down in the realm of minor bugs?

I would say that we are now in the realm of minor bugs (??? which ones???)

>
>> @node Proposed Extensions
>> @section Proposed Extensions
>
> [...]
>
>> @item
>> Flag to cause the compiler to distinguish between upper and lower case
>> names.  The Fortran 95 standard does not distinguish them.
>
>
> Does anyone actually think this is a good idea?

No - whilst I agree taht it is an irritant in the standard, I do not 
think that we should add any more non-standard features.  Let's get F95 
+ TRs right!

>
>
>> @item
>> Flag to compile lines beginning with ``D''.
>>
>> @item
>> Flag to ignore lines beginning with ``D''.
>
>
> We have this implemented, right?
>
> I'm not going to quote all the rest, but could someone a little more 
> knowledgable than me take a look through and see what other things are 
> now valid?
>
>> @item
>> Support for Fortran 200x. This includes several new features including
>> floating point exceptions, extended use of allocatable arrays, C
>> interoperability, Parameterizer data types and function pointers.
>> @end itemize
>
>
> This should probably be up in the "Status" section or somewhere, 
> rather than in with the rest of the proposed extensions, I'd think.
>
> In addition, the TR15581 allocatable-components-and-such support 
> should be explicitly mentioned -- is it reasonable to say that this is 
> in progress and an implementation will be available soon?  (In 
> particular, what's the projected status of this for the 4.2.0 release?)

Erik has been busy - I just restarted trying to clean up the problems 
with constructors.  The fundamentals are there and it would be my 
opinion that we go for 4.2.0 with what we have.  It might be an idea to 
commit the latest version at the end of next week.

>
> Going at this from the other direction, are there additions to this 
> section that ought to be made?

No - if you can get it up to date, that would be an immense service.

Paul