Re: [RFC, PATCH, fortran] PR fortran/60255 Deferred character length

[Dominique d'HumiÃres <dominiq at lps dot ens dot fr>]

Dear Paul,

The problem for oo.f90 is pr 55901.

I am updating my working tree with Andreâs patch.

Cheers,

Dominique

> Le 8 dÃc. 2014 Ã 21:20, Paul Richard Thomas <paul.richard.thomas@gmail.com> a Ãcrit :
> 
> Dear Andre,
> 
> s/furure/future/ :-)
> 
> Why are you using a double underscore in get__len_component?
> 
> More seriously, I think that the len field should be added unconditionally to unlimited polymorphic variables. Otherwise, you might find unlimited polymorphic variables that are created in an already compiled module/subprogramme arriving without the requisite field.
> 
> Michael Metcalf has posted an example that makes use of unlimited polymorphism at ftp://ftp.numerical.rl.ac.uk/pub/MRandC/oo.f90 . gfortran does not work correctly with it at the moment because of the lack of a len field. Removing all the string input allows it to run correctly. I think that you should ensure that your patch fixes the problem.
> 
> A slight obstacle is that the substring at line 216 causes the emission of:
>     type is (character(*))
>                           1
> Error: Associate-name '__tmp_CHARACTER_0_1' at (1) is used as array
> 
> Just retaining print *, 'character = "', v, '"' allows the example to compile
> 
> ifort compiles and runs it successfully and so I think that it would be nice if gfortran catches up on this one.
> 
> Parenthetically, I wonder if this is not the time to implement PR53971... including responding to Mikael's comment?
> 
> Anyway, this is a good start in the right direction. Please persist!
> 
> Thanks
> 
> Paul
> 
> 
> On 8 December 2014 at 18:38, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi all,
> 
> please find attached a more elaborate patch for pr60255. I totally agree that
> my first attempt was just scratching the surface of the work needed.
> 
> This patch also is *not* complete, but because I am really new to gfortran
> patching, I don't want to present a final patch only to learn then, that I have
> violated design rules, common practice or the like. Therefore please comment
> and direct me to any sources/ideas to improve the patch.
> 
> Topic:
> The pr 60255 is about assigning a char array to an unlimited polymorphic
> entity. In the comments the concern about the lost length information is
> raised. The patch adds a _len component to the unlimited polymorphic entity
> (after _data and _vtab) and adds an assignment of the string length to _len
> when a string is pointer assigned to the unlimited poly entity. Furthermore is
> the intrinsic len(unlimited poly pointing to a string) resolved to give the
> _len component.
> 
> Yet missing:
> - assign _len component back to deferred char array length component
> - transport length along chains of unlimited poly entities, i.e., a => b; c =>
>   a where all objects are unlimited poly and b is a string.
> - allocate() in this context
> 
> Patch dependencies:
> none
> 
> Comments, concerns, candy welcome!
> 
> Regards,
>         Andre
> 
> On Sun, 17 Aug 2014 14:32:21 +0200
> dominiq@lps.ens.fr (Dominique Dhumieres) wrote:
> 
> > > the testcase should check that the code generated is actually working,
> > > not just that the ICE disappeared.
> >
> > I agree. Note that there is a test in the comment 3 of PR60255 that
> > can be used to check the run time behavior (and possibly check the
> > vtab issue).
> >
> > Dominique
> 
> 
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
> 
> 
> 
> -- 
> The knack of flying is learning how to throw yourself at the ground and miss.
>        --Hitchhikers Guide to the Galaxy