Re: [Rd] Calling FORTRAN function from R issue?

From: Berwin A Turlach <>
Date: Tue, 06 Mar 2012 21:37:03 +0800

G'day Berend,

On Tue, 6 Mar 2012 13:06:34 +0100
Berend Hasselman <> wrote:

[... big snip ...]

> But I would really like to hear from an Rexpert why you
> shouldn't/can't use external here in the Fortran.

Probably less a question for an Rexpert but for a Fortran expert....

If you insert "implicit none" (one of my favourite extensions that I always use) as the first statement after

        subroutine callzdotc(retval,n, zx, incx, zy, incy) you will see what is going on. The compiler should refuse compilation and complain that the type of zdotc was not declared (at least my compiler does). For FORTRAN to know that zdotc returns a double complex you need the

        double complex zdotc
declaration in callzdotc.


        external double complex zdotc
would be necessary if you were to call another subroutine/function, say foo, that accepts functions as formal arguments and you want to pass zdotc via such an argument. Something like

	subroutine callzdotc(....)
        external double complex zdotc
        call foo(a, b, zdotc)

	subroutine(a, b, h)
	double complex h, t
	t = h(..,..,..,..)

In C, the qualifier (or whatever the technical term is) "external" is used to indicate that the function/variable/symbol is defined in another compilation unit. In FORTRAN77, "external" is used to tell the compiler that you are passing a function to another function/subroutine. At least that is my understanding from what I re-read in my FORTRAN documentation.  

Thus, perhaps strangely, if there is only a

        external double complex zdotc
declaration in your subroutine, the compiler doesn't know that a call to zdotc will return a double complex but will assume that the result has the implicitly defined type, a real*8 IIRC. So zdotc is called, and puts a double complex as result on the stack (heap?), but within callzdotc a real as return is expected and that is taken from the stack (heap?), that real is than coerced to a double complex when assigned to retval. Note that while I am pretty sure about the above, this last paragraph is more speculative. :) But it would explain why the erroneous code returns 0 on little-endian machines.

HTH. Cheers,         



        Berwin mailing list Received on Tue 06 Mar 2012 - 13:40:35 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Tue 06 Mar 2012 - 14:50:24 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive