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

[Paul Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Andre,

I can probably give you a good start with fortran-dev. I got quite a long way to implement the systematic use of pointer arithmetic instead of array index manipulation for descriptor arrays. I ran into some perplexing regressions that I was unable to fix in the time that I had. Give me a few days to remind myself of where I got to.

Cheers

Paul

Sent from my iPhone

> On 09 Dec 2014, at 10:42, Andre Vehreschild <vehre@gmx.de> wrote:
> 
> 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