From: Richard Maine on
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

"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
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
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
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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: managing identities
Next: Call Tree Generator