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