Re: [PATCH, fortran] Revival of AUTOMATIC patch
On Fri, Sep 25, 2015 at 07:23:53PM +0200, Paul Richard Thomas wrote: > > Frankly, I would accept the patch with the proviso that: > (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...; > (ii) The feature is set in conflict with the new features that FX > mentions, especially coarrays and bind C; and Did we also need to add Cray pointers to the list of possible conflicts? I can't remember the details of the implementation, but I do recall that Asher added a number of conflicts for F95+ attributes. -- Steve
Re: [PATCH, fortran] Revival of AUTOMATIC patch
Dear Jim, FX and Jerry, Frankly, I would accept the patch with the proviso that: (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...; (ii) The feature is set in conflict with the new features that FX mentions, especially coarrays and bind C; and (iii) As FX says, a good look at the testcases. It is a rather standalone patch and so should be quite self-maintaining. I suspect that it might even be quite useful to optimise code for devices such as the Intel phi by dint of explicitly preventing memory swopping. If the other maintainers are happy with the above provisos, I suggest Jim that you make the necessary changes and resubmit. If you are not in a position to do this, I could apply myself to it on a timescale of the next few weeks. With best regards Paul On 25 September 2015 at 16:26, FX wrote: >>> All in all I’m skeptical of adding even more old language extensions with >>> little demand when we have a hard time filling up gaps in the standard. Each >>> addition adds to maintainance load, especially as they might not interact >>> too well with more modern features. (For example coarrays or BIND attribute, >>> which were not around when AUTOMATIC was in use.) >>> >>> I don’t find any request for this feature in the whole bugzilla database. >> >> That's understandable. We'll maintain this feature in our own delta. I felt >> it >> was in the spirit of open source to offer it in case it was useful. >> >> Thanks for taking the time to review it. > > I definitely appreciate your contribution! And because it is now archived in > the mailing-list archives, if people are interested in the future they can > definitely pick it up. It is a rather “standalone” patch, I don’t think it > would bitrot fast. > > But maybe other developers feel differently about it, in which case we’ll > have a more “technical” review (mostly of the testcases needed, I think). > > Thanks again, > FX -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [PATCH, fortran] Revival of AUTOMATIC patch
>> All in all I’m skeptical of adding even more old language extensions with >> little demand when we have a hard time filling up gaps in the standard. Each >> addition adds to maintainance load, especially as they might not interact >> too well with more modern features. (For example coarrays or BIND attribute, >> which were not around when AUTOMATIC was in use.) >> >> I don’t find any request for this feature in the whole bugzilla database. > > That's understandable. We'll maintain this feature in our own delta. I felt > it > was in the spirit of open source to offer it in case it was useful. > > Thanks for taking the time to review it. I definitely appreciate your contribution! And because it is now archived in the mailing-list archives, if people are interested in the future they can definitely pick it up. It is a rather “standalone” patch, I don’t think it would bitrot fast. But maybe other developers feel differently about it, in which case we’ll have a more “technical” review (mostly of the testcases needed, I think). Thanks again, FX
Re: [PATCH, fortran] Revival of AUTOMATIC patch
On Thu, Sep 24, 2015 at 10:58:41PM +0200, FX wrote: > > I think I appreciate what you are trying to do here. I don't intend to > > sound > > negative here, but if the keyword AUTOMATIC does nothing > > The testcase given is not an example of useful AUTOMATIC. I think it is > meant to be used to oppose an implied SAVE attribute, e.g. a variable with > explicit initialization or the BIND attribute. Indeed, in the case of > implied SAVE by initialization, there it is a little bit more work because > you have to move the initialization to the executable part of the code. But > that’s not impossible. The automatic_1 test case was only intended to demonstrate that AUTOMATIC has an effect, not a useful one. I don't have the option of being able to rewrite all our source code, so I am trying to make a compiler which mimics some older proprietary ones; I understand that these features may not be useful to someone writing new Fortran code. > > All in all I’m skeptical of adding even more old language extensions with > little demand when we have a hard time filling up gaps in the standard. Each > addition adds to maintainance load, especially as they might not interact > too well with more modern features. (For example coarrays or BIND attribute, > which were not around when AUTOMATIC was in use.) > > I don’t find any request for this feature in the whole bugzilla database. That's understandable. We'll maintain this feature in our own delta. I felt it was in the spirit of open source to offer it in case it was useful. Thanks for taking the time to review it. Jim
Re: [PATCH, fortran] Revival of AUTOMATIC patch
> I think I appreciate what you are trying to do here. I don't intend to sound > negative here, but if the keyword AUTOMATIC does nothing The testcase given is not an example of useful AUTOMATIC. I think it is meant to be used to oppose an implied SAVE attribute, e.g. a variable with explicit initialization or the BIND attribute. Indeed, in the case of implied SAVE by initialization, there it is a little bit more work because you have to move the initialization to the executable part of the code. But that’s not impossible. All in all I’m skeptical of adding even more old language extensions with little demand when we have a hard time filling up gaps in the standard. Each addition adds to maintainance load, especially as they might not interact too well with more modern features. (For example coarrays or BIND attribute, which were not around when AUTOMATIC was in use.) I don’t find any request for this feature in the whole bugzilla database. FX
Re: [PATCH, fortran] Revival of AUTOMATIC patch
On 09/24/2015 04:52 AM, Jim MacArthur wrote: > Hi all, I'm following up on some old work my colleague Mark Doffman did to > try > and get support for the AUTOMATIC keyword into trunk. In the enclosed patch > I've addressed the problem with it accepting 'automatic' outside -std=gnu (it > will now only accept AUTOMATIC under -std=gnu or -std=legacy). I've also > added > some test cases and documentation. > > To address some of the other questions about this patch: > > * AUTOMATIC isn't in any official standard, but is supported by the > Sun/Oracle > Fortran compiler: > http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn79/index.html#z400073dc651 > > and the IBM XL compiler: > https://www-304.ibm.com/support/docview.wss?uid=swg27018978&aid=1 > > * Making this patch is our second choice after modifying our source code. The > scale of our source means it's not practical to manually modify it. For other > legacy features we've been able to do some automated transforms, but we can't > figure out any way to do this for AUTOMATIC. There's a chance there will be > some other people out there stuck with legacy code who will benefit from this > change. > I think I appreciate what you are trying to do here. I don't intend to sound negative here, but if the keyword AUTOMATIC does nothing how difficult is it really to just run a script on all your source code using something like sed and just strip it out. 5 minutes to develop the script, 13 seconds to run it. Or maybe a preprocessor directive that defines AUTOMATIC as '' I must be missing something here. Regards, Jerry
