[Patch, fortran] PR51976 - [F2003] Support deferred-length character components of derived types (allocatable string length)

[Paul Richard Thomas]

Dear All,

I too have quite mixed feelings about this patch.  It is not really
appropriate for stage 4. Whilst the release managers have been quite
relaxed about some of our wrong code fixes, I think that their
patience might be quite stretched by this patch. In addition, it
really can be much better done with improved array descriptors.....

Let's have a vote on it.  I'll load it up on my tree and check it for
isolation from everything else and, if I get a unanimous vote
 by Sunday, I will apply it then.

Cheers

Paul


On 21 February 2014 15:10, Dominique Dhumieres <dominiq@lps.ens.fr> wrote:
> Wrongly sent to bugzilla!-(
>
> Hi all,
>
>> I think it went as follows: We found out that some code doesn't - in
>> particular code which uses array-valued deferred-length characters.
>> After trying to fix it, you (Paul) decided that the simplest way to fix
>> it would be the new array descriptor - and then it got stuck.
>
> A list of known problems can be found at
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976#c8
>
>> Regarding this patch, I have mixed feelings.  I think it is a much wished
>> feature - but I am not sure about the stability of the patch and it is
>> rather large, given that we are in stage 4.
>
> I have the patch in my working tree since more than a year without any
> related problem. Indeed I had to practice minor surgery to keep it alive.
> AFAICT the changes are quite localized and I don't expect any major
> problem if it is committed.
>
>> Regarding the new array descriptor: I think it would be useful if we
>> could get the new descriptor working early in the GCC 4.10/5.0/2015
>> development stage.  I think the main large task is to convert all all
>> remaining stride-based code to stride-multiplier code without breaking
>> vectorization and causing other regressions.  Additionally, it would be
>> nice to get rid of "offset" - and have in the descriptor always an
>> lower_bound of 0, except for pointers/allocatables (cf.  TS29113).  I
>> think the version on the branch is in a relatively good shape; however,
>> the stride and offset changes seem to be of such a kind that one needs to
>> modify several code locations simultaneously - otherwise, it will break
>> badly.  Additionally, all remaining regressions have to be fixed.  When
>> that's done, adding some extra field is all what's needed.  (As follow
>> up, enough remains to be done: I'd like to use it for all class(*),
>> possibly even for nonarray class(type), assumed-rank needs an update,
>> assumed-shape/-rank/deferred-shape character arrays also have to be
>> adapted (also mandated by TS29113 for interop).  And we should do an ABI
>> cleanup in libgfortran as we have now the chance to break the ABI.) - Is
>> anyone volunteering?
>
> I think the new array descriptor should be given the highest priority and
> fortran-dev merged to trunk as soon as the last regression is fixed. My
> tests show that its present state is quite close (note regtesting should
> be done for both -m32 and -m64: some scanning tests fail with -m32).
>
> Cheers,
>
> Dominique



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy