[R] R-Fortran question (multiple subroutines)

[Berwin A Turlach]

G'day Remko,

On Mon, 25 Oct 2010 15:33:30 +1100
Remko Duursma <remkoduursma at gmail.com> wrote:

> apologies if this is somewhere in a manual, I have not been able to
> find anything relevant. 

You probably have to set some appropriate flags and the information
should be somewhere in the manual of your compiler. Though, "Writing R
Exensions" will tell you now to change/specify flags for compilers.

> I run Windows Vista.

My condolences. :)

> But is it possible to have more than one subroutine in my source file,
> one depending on the other? 

Yes.

> I.e, my code looks something like this:
> 
> subroutine f(x,y,z)
> 
> call g(x,y,z)
> 
> end
> 
> subroutine g(x,y,z)
> 
> z = x*y
> 
> end
> 
> calling this from R shows that subroutine g is not called. 

What do you mean with "g is not called"?  How did you assert this?  

If the code functions correctly, then g has to be called, either
explicitly or implicitly (e.g. if it was inlined).

Do you mean that when you compile the code and load the resulting DLL
from R, you can only call subroutine f via .Fortran but not subroutine
g? 

> The code compiled as executable works fine.

What do you mean with "compiled as executable"?  The snippet that you
showed would not compile as an executable as there is no main program.
So what do you mean with "works fine"?  That you can call the
subroutine g from the main program that you use when creating an
executable?

My guess, based on this snippet, is that your compiler notices that
subroutine g is not really needed and replaces the call to g within f
by the body of g and does not create a separate entry point for g in
the compiled object; a process known as in-lining (IIRC) and typically
used by compilers if high levels of optimisations are requested.  The
compiler does not know that you intend to call g later directly from R
via .Fortran, all it sees is the code in the file and, if high
optimisation is requested, it may feel free to rearrange the code to
stream-line it (e.g. by in-lining).  

So possible solutions could be:

1) ask for a lower level of optimisation 
2) tell the compiler not to do in-lining (flag --no-inline??)
3) put the routines into separate files, compile the files separately
   and then link all the resulting object files together into a DLL.
   AFAIK, optimising/inlining across separate files is a tricky issue
   so few, if any, compilers would do so.
4) Check whether there is an option to specify which exportable
   symbols have to be in the DLL in the end.

Cheers,

	Berwin

========================== Full address ============================
Berwin A Turlach                      Tel.: +61 (8) 6488 3338 (secr)
School of Maths and Stats (M019)            +61 (8) 6488 3383 (self)
The University of Western Australia   FAX : +61 (8) 6488 1028
35 Stirling Highway                   
Crawley WA 6009                e-mail: berwin at maths.uwa.edu.au
Australia                        http://www.maths.uwa.edu.au/~berwin