> In article <30eb25a2-914c-4d0d-8635-618d9b000...@w24g2000prd.googlegroups.com>,
>         Damian rouson.net> writes:
>
>
>

>> Since I can't report any new bugs, I'm glad to volunteer to work on
>> the things that excite me the most.  I would be very excited to see
>> the following implemented and will contribute if someone can give me
>> specific guidance on where to start with these:
>> 1. allocatable scalars
>> 2. final procedures

>
> One of those Google SoC students mentioned elsewhere in this
> already undertook final procedures.  The patch will appear in 4.5.
>

>> 3. polymorphic variables
>> 4. type guard statements
>> These are the most important things I need from gfortran to get it to
>> compile a new code I'm working on.  Of the compilers I've tried, it
>> currently only compiles with IBM XL Fortran.

>
> If you (and Arjen) want to ease into contributing to gfortran,
> the easiest approach is contributions to the gfortran manual.
> Read the current manual and fix grammar and spelling issues,
> or expand the explanation of a feature.  There's a bug report
> to check that intrinsic procedures use the Standard's name
> convention for formal arguments in error messages.  This entails
> reading the standard and the functions add_function and
> add_subroutine in intrinsics.c, and fixing any discrepancies.
>
> Having spent some time searching for tutorials on C binding,
> adding a tutorial section to the manual may be an acceptable
> contribution.
>
> There's also a gfortran internals manual that Daniel Kraft started.
> Read the source code, ask questions on fortran@gcc, and then
> document some internal data structure.  This will lead to contributing
> patches to fix actual bugs.
>
> As a semi-retired gfortran hacker, I can assure any contribution
> would be welcomed.
>
> --
> steve