New year's Resolutions

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

First, let me wish everybody a happy, healthy and prosperous new year.

Second, let me explain the subject:

I have a mind this weekend to tidy up my hard-drive and, in an attempt 
to get a bit more organized, to order my various incomplete gfortran 
projects to get them ready for submission.  I would appreciate opinions 
on priorities.  Many have already had preliminary exposures on the list 
and some are at the stage where I have figured out what to do.  Without 
input from others, I will attack them roughly in the order below.

(i) The inline DOT_PRODUCT.  This has been tested by various people, on 
a number of platforms.  At worst, it does no harm and, for short 
vectors, it is a lot faster than the library version.  I thought to have 
a switch between inline and library according the length of the vectors; 
somewhere in the 16-32 range seems right.

(ii) The improvements in the dependency analysis for straight 
assignments.  It might be worth implementing the simple version, seen on 
the list, right away.  It has been further simplified by the correction 
to the error in gfc_is_same_range; I must have commited this sometime 
but I am blowed if I can find the ChangeLog entry.  This function is 
only referenced by a commented out piece of code and works fine if 
called from gfc_check_section_vs_section.  The extra work would be to 
evaluate simple expressions, as indicated by the TODO in the latter 
function.  A really ambitious project would be to reverse loop order, in 
an attempt to avoid temporaries (I have not forgotten, Dominique!).

(iii) The library version of MOD could be implemented - this was 
discussed on the list.  I got stuck on forcing the fast-math version.  
Otherwise, the inline MOD can be improved to sort out what happens at 
large values of arg1/arg2.

(iv) I have a number of constraints and restrictions, more or less ready 
to fly; most notably on INTENT and automatic character lengths.  These 
patches are part of a continuing campaign to clear Joost VandeVondele's 
huge number of PRs.

(v) I can see how to mend elemental subroutines; these are not 
scalarized at at all and therefore die a spectacular death in 
gfc_conv_func_call.  The trick will be to set up a scalarization loop, 
walk the arguments, as done for elemental functions, and call the 
subroutine from within the loop.

(vi) I have given thought to aliassing of components of derived type 
arrays by arrays of the same type as the component.  In the case of 
dummy arguments, a simple kludge would be to copy back the temporary to 
the derived type.  In the longer term, we need to improve the 
referencing of arrays, so that both dummies and pointer assignments work 
correctly.

(vii) In contemplating (vi), I read the constraints on character lengths 
for assignments (dummy length <= actual length, where length is 
char_len*array size)  and pointer assignments(lhs char_len = rhs 
charlen).  These can be applied and would clear up a number of PRs.

(viii) I have mapped out a reform of read_module and use_module that 
would make module namespaces that would be read on subsequent USEs of a 
module.  This would both speed up compilation and make module.c more 
maintainable.

(ix) I have an outline plan for implementing the F2003 allocatable 
features - of derived types, dummy arguments and function results.  
This, to me, is one of the most desirable F2003 TODOs and is already 
implemented in commercial compilers.  Most of the hooks to do this in 
gfortran are already in place (Thanks, Paul B).

(x) Following the recent exchange on the list, I am due to take a look 
at the gfortran web pages and to make proposals for tidying 
up/updating/linking to the Wiki.

I wrote out, for my own use, a similar list last December 31st.  To my 
considerable surprise, they are all done and more besides, with the 
exception of (vi).

If others are working on any of the above, let me know and we can work 
out how to collaborate or to share what we have already done.  Erik, I 
have noted your interest in (v) and (ix); are you working on them?  It 
might be nice to see what projects other people have in mind; 
non-binding, of course but as an aid to sorting out priorities.

One again, best wishes for 2006

Paul