On Mon, Oct 17, 2011 at 12:14:56PM -0700, Alan Irwin wrote: > @Arjen: There is a question for you at the end concerning > deprecating/retiring our f77 bindings and examples. > > On 2011-10-14 08:26+0100 Andrew Ross wrote: > > [...] > >> FFLAGS is used for both f77 and f95 compiles which makes it hard to > >> tailor the flags for different standards. Again, it is a limitation > >> of cmakes handling of these things. > [...] > > FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra > [...] > > So far I've not even looked at [...] fortran. If someone with more fortran > > insight wants to take that on it would be good. > > Hi Andrew: > > In connection with a different project I have just looked at the -std > capability of gfortran, and it makes for interesting reading: > > <quote from info gfortran> > `-std=STD' > Specify the standard to which the program is expected to conform, > which may be one of `f95', `f2003', `f2008', `gnu', or `legacy'. > The default value for STD is `gnu', which specifies a superset of > the Fortran 95 standard that includes all of the extensions > supported by GNU Fortran, although warnings will be given for > obsolete extensions not recommended for use in new code. The > `legacy' value is equivalent but without the warnings for obsolete > extensions, and may be useful for old non-standard programs. The > `f95', `f2003' and `f2008' values specify strict conformance to > the Fortran 95, Fortran 2003 and Fortran 2008 standards, > respectively; errors are given for all extensions beyond the > relevant language standard, and warnings are given for the Fortran > 77 features that are permitted but obsolescent in later standards. > </quote> > > So gfortran has no support for a strict Fortran 77 standard. That's > probably okay. My experience with strict Fortran 77 is it is a real > pain to use; historically there were a lot of extremely useful > extensions to that standard for VAX/VMS Fortran that became a > pseudo-standard themselves. It is that pseudo-standard that I have > tended to use over the years for the "Fortran 77+" scientific > libraries and applications that I have implemented so it is > likely that my contributions to our standard f77 examples includes > those language extensions. > > So given the state of legacy fortran support in gfortran, here is what > I think you should do. > > * Do your initial Fortran tests with f77 disabled. This should allow > you to use -std=f95 to weed out any problematic code in our f95 bindings > and examples. > > * Finish by enabling f77 and using -std=legacy. This is a pretty > weak test since it does not discriminate in the slightest against pure > Fortran 95 code getting into our f77 bindings and examples, but I > think you should perform this test just in case it discovers some > "Fortran 77" code that is problematic in general. > > * At some point I think we should deprecate and then retire the f77 > bindings and examples. A lot of the scientific libraries and > applications I implemented over the years were written in "Fortran > 77+", and my knowledge of modern Fortran is still pretty shaky. > Nevertheless, even I can see that the Fortran 9x and 20xx changes were > a long-overdue revolutionary change to Fortran 77 that has turned > Fortran into an extremely powerful and interesting language. So I am > not sure how much longer it would be worthwhile for us to put any > effort into our f77 bindings and examples when there is a lot of > interesting things we could be doing with our f95 bindings and > examples instead. > > @Arjen: I would be extremely interested in your take on this matter > since you probably have the best knowlege here of the overall state of > Fortran. Also, since you are the guy that has been maintaining our f77 > bindings and examples I think the decision about when to > deprecate/retire these bindings and examples is strictly your call. > Nevertheless, I do suggest you at least consider the matter in terms > of cost of maintaining those f77 bindings/examples versus the benefit > to our users. The key part of that analysis is your best guess at > whether there are still substantial numbers of Fortran users out there > who still prefer using our f77 rather than f95 bindings and examples. > My guess is there are not, but I trust your guess more than mine. :-)
I've done this and the f95 bindings are now compliant with the f95 standard apart from 1) The iargc and getarg intrinsics which are used to get command line arguments. These are a gnu extension. Fortran 2003 does include different intrinsics for getting command line arguments. We probably should support these in the long term, but no idea whether current compilers adhere to that standard. 2) The flush intrinsic in example 14. This is another gnu extension to f95. Again fortran 2003 includes a flush function with the same capabilities so updating our target fortran version would fix this. I had to rework a lot of the BOZ constants (like z'00FF') for the hex integer 00FF. In f95 these are ONLY allowed in data statements. As of f2003 you can also use them in int, float, dble, cmplx statements. This is kind of restrictive though! Our current use was a gnu extension. I also remove the use of the exit intrinsic in the examples. It's not standard and to be honest "stop" is fine for our use and keeps things clean. I do not intend working on the f77 bindings. The C side could be cleaned up in the same way as the f95 bindings if anyone fancies it. Andrew ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
