On 02/20/2012 11:06 PM, Alexei Matveev wrote:
> I dont quite get the calling convention of Intel 11.1 for
> interoperable functions. An identity function "id" for a "short structure" [...]
With BIND(C), the calling convention should be the same as with the
accompanying C processor, i.e. as with GCC's gcc in case of gfortran and
as with Intel's icc in case of ifort. As I get with icc the (expected)
movq %rdi, %rax #9.9
I believe that you have found a bug in ifort.
> Quite recently I had to give op on linking Intel compiled executable
> with Gfortran compiled libraries, presumably, because of the calling
> conventions with functions that return (double precision) complex
> numbers. Aka. ZDOTC() "bug". I think I need to understand the options/
> differences better. A would appreciate any comments, thanks in advance.
Using BIND(C), the ABI should be the same - ignoring issues like the one
above - related to short structures.
Regarding functions returning complex numbers or single-precision
floats: gfortran follows the platform ABI and C99 by really returning
those values. Other compilers follow older conventions of C compilers
and in particular of the "f2c" (Fortran to C) compiler. One can argue
which choice is better, there are proponents of either choice.
gfortran supports the flag -ff2c to use the f2c calling convention,
which you could try. In any case, mixing different calling conventions
is a bad idea. See also
Another warning:* If you use an ifort-compiled function "f" which
returns a LOGICAL, with a gfortran-compiled code which calls ".not.
f()": The result might not be what you expected as .true. is in ifort
"-1" (GCC and C99: "1") and - with higher optimization - GCC just flips
one bit to negate a Boolean value. Thus, ".not. (-1)" becomes "-2" is
regarded as .true. (expected: not .true. == .false.). At least with
BIND(C) that's a bug in ifort as it violates C99; on the other hand, as
it works with the "accompanying processor" (i.e. icc), one can argue
that it is not a bug.