Prev: managing identities
Next: Call Tree Generator
From: Richard Maine on 4 Feb 2010 02:06 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Fortran compilers lately are rarely written in Fortran. I once had the idle thought of doing such a thing, or anyway a front end to connect to something like the GCC back end. I even briefly played with it a little, but didn't put in enough time to get very far (at all). I found it discouraging that in order to really work on any of the open source Fortran compilers, you have to work in C. Not interested in that. Yes, I know that the line about how one can contribute by doing things other than coding, but it doesn't seem the same to me (particularly as I have experience in submiting what I regarded as high priority bug reports and being told that nobody was willing/able to dig into the needed part of the code). Modern Fortrans have the features that you'd need to make it reasonably doable. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Colin Watters on 4 Feb 2010 02:38 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:boOdnX0MIfh1lffWnZ2dnUVZ_qpi4p2d(a)supernews.com... >> Intel Fortran has a "generated interface checking" option. You compile >> your sources with -warn interface (/warn:interface on Windows) and it >> automatically generates interface blocks and modules for subroutines and >> functions and checks calls against them, warning you of mismatches. For >> best success, I suggest two builds, leaving the generated .mod files in >> place after the first build, because a call to a routine that has not >> yet been compiled can't be checked. > > Does IVF create a .MOD file for each .F file ? Do the > .MOD file(s) have to put into a certain area for the .F > files to look them (my .F files are scattered over about > 100 directories) ? > It creates one .F90 file (which compiles to yield one .MOD file) for every PROCEDURE. So the files in your source that contain 2 or more functions and/or subroutines gives rise to 2 or more .MOD files. It puts the modules in the same place as it puts the .obj files; there may be a compiler option to control this. I compile everything through MS Visual Studio so it is all set up to Just Work; I suspect you are using a command line. The compiler has about 50 zillion options so it must be possible to specify where to put the files, and where to expect them to be. I can't look just now coz I'm not yet in the office. Hopefully Steve will give you chapter and verse on this (surprsed he hasn't already). You could also ask on the Intel Fortran compiler Forum http://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/ . -- Qolin Email: my qname at domain dot com Domain: qomputing
From: analyst41 on 4 Feb 2010 05:30 On Feb 4, 1:14 am, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > robin <robi...(a)bigpond.com> wrote: > > (snip, someone wrote) > > >> Would be possible to write a fortran program to check > >> argument lists? > > That wouldn't do what Lynn wanted, which was to check > > argument types as well as numbers of arguments. > > It would be possible, but not easy. > > It takes much of the front end of a Fortran compiler to do it. > Fortran compilers lately are rarely written in Fortran. > > -- glen I am sure the these two are easy to write in Fortran (1) Recognize lines that start a sub-program declaration (2) extract the number and names of arguments You then have to keep reading lines until the first exceutable statement (is that easy, may be not). Is it going to be very hard to see what rank and type has been declared for each argument? Perhaps - but still a lot easier than an entire compiler, I think.
From: glen herrmannsfeldt on 4 Feb 2010 06:44 analyst41(a)hotmail.com <analyst41(a)hotmail.com> wrote: (snip) > I am sure the these two are easy to write in Fortran > (1) Recognize lines that start a sub-program declaration > (2) extract the number and names of arguments Well, you also want the type of the arguments, which requires much more parsing. There is also the complication of continuation lines. > You then have to keep reading lines until the first exceutable > statement (is that easy, may be not). > Is it going to be very hard to see what rank and type has been > declared for each argument? > Perhaps - but still a lot easier than an entire compiler, I think. Most of the front end of a compiler is tokenizing and parsing. Many of the complications of non-significant blanks in fixed format go away in free format. REALFUN *CTIONX(A,B) INT *EGERA COMPLE *XB X=A+AIMAG(B) RETURN END X=& SUBROUTINE(C,D) -- glen
From: Steve Lionel on 4 Feb 2010 12:48
On 2/3/2010 6:38 PM, Lynn McGuire wrote: > Does IVF create a .MOD file for each .F file ? Do the > .MOD file(s) have to put into a certain area for the .F > files to look them (my .F files are scattered over about > 100 directories) ? Colin has it right. The generated .mod file (a corresponding .f90 file is also created but that's just for human convenience) is placed (and looked for) in the folder that other .mod files go, which can be specified by the /module option. In a Visual Studio project, this is by default the "intermediate" directory, usually named Debug or Release. This feature is also in our Linux and Mac OS compilers. -- Steve Lionel Developer Products Division Intel Corporation Nashua, NH For email address, replace "invalid" with "com" User communities for Intel Software Development Products http://software.intel.com/en-us/forums/ Intel Software Development Products Support http://software.intel.com/sites/support/ My Fortran blog http://www.intel.com/software/drfortran |