[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

["dominiq at lps dot ens.fr" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976

--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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