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 <ve...@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 > > domi...@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: ve...@gmx.de
