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

[Andre Vehreschild <vehre at gmx dot de>]

Hi Paul,

> s/furure/future/ :-)

Hups, fixed.

> Why are you using a double underscore in get__len_component?

Because the component is called _len. The routine should be called "get _len
component", but spaces aren't allowed :-) Anyways, does this violate some style
guide? Should I remove one of underscores?

> 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.

I was thinking about that, too. For a start I just wanted to give an idea of
where this is going. When more gfortran gurus vote for the unconditional add to
u-poly variables, then I will change it. 

> 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

Ok, I take a look at it. As I am paid to fix certain bugs that prevent
compiling another software, I will not prioritize working on 55901 as long as
it is not needed in the software I focus on. Sorry for not being more
enthusiastic, but there are more than 8 prs (and only one down yet) I have to
fix and time is limited.

What I did not mention in the previous mail is that I also plan to implement
this fixes in the fortran-dev branch with the new array descriptor. Given that
there is no other volunteer. :-)

Please continue commenting.

Regards,
	Andre

> 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
> >
> 
> 
> 


-- 
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 241 9291018 * Email: vehre@gmx.de