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
         ret                                                     #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 
http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

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.

Tobias