Backporting, was: Re: [PATCH, libgfortran] PR24794 namelist input of character array]

[Paul Thomas]

Steve,

>
>IMHO, 4.0 should be left alone after 4.1 is released.  We, the gfortran
>developers, simply don't have enough man power for 2 branches and
>mainline.
>
>
I agree. We barely have enough manpower for two branches.....

>>I'm not so sure that we're in a state where our policy of backporting
>>all fixes to 4.1 costs us more than it gains us, so we might want to
>>continue this.
>>
>>Opinions?
>>
>
>Mainline and 4.1 are in sync.  I think we should try to maintain
>this for as long as possible.  The biggest change coming in mainline
>with major implications for gfortran is openmp.  When the openmp
>infrastructure is meged into mainline, I think that is where we will
>again diverge unless rth, Diego, and Jakub backport all of openmp to
>4.1.
>
I think that this is right.

It seems to me that, apart from the continuous battle against 
non-structural bugs and performance bottlenecks, there are three areas 
that we should try to target before the 4.2 release:

(i) The reform of array representation. We must introduce aliassing of 
components of arrays of derived types. It is one of the more important 
features of F95 and, as far as I am aware, it is the only one that is 
missing rather than broken.
(ii) The handling of modules could usefully be revamped. I had in mind 
to write modules as at present but to read them into their own 
namespaces, attached to the global namespace, from where they are used. 
I believe that this will be more transparent and certainly much faster 
for complicated programs.
(iii) I think that we should add the SWG F95 extensions to allocatable 
arrays. The commercial compilers now have these extensions as a 
"fortran2003" feature for some very good reasons. Most of the 
infrastructure to do this is already present in gfortran.

I feel more than a bit daunted by (i); how about it Jakub, Paul, Steven 
or Richard? It might be difficult to maintain synchronism if this is 
implemented. I had a mind to have a stab at (ii) myself, during my next 
long trip from January to February. If I were not having such a hard 
time with PR15809, I might have felt energised to have a stab at (iii) 
as well... we'll see!

Anyway, I think that it is feasible to maintain synchronism between 
trunk and 4.1, unless we implement (i); even then, it might well be 
possible.

Paul