Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

C-interop issue

mecej4
Honored Contributor III
1,202 Views
I have run into an issue with C-interoperability that is perplexing.

Consider a Fortran function intended to be called from C. The function takes as argument a C-pointer by value, prints out something using that pointer, and returns the input pointer. Here is a simple example, in which I have commented out the I/O statements, so the function is trivial; it returns its argument pointer.

[fortran]function ffun(arg) bind(C)
use iso_c_binding
implicit none
type(c_ptr), value :: arg
type(c_ptr) :: ffun

!integer :: i
! write(*,10)transfer(arg,i)
! 10 format(1x,' ARG address : ',Z16)

ffun=arg

return
end function ffun
[/fortran]
On Linux, IFort 12.0.3 (X64) produces this assembly code:

[bash]                mov    %rdi,%rax
mov %rsi,(%rdi)
retq
[/bash]
whereas GFortran 4.5 leaves out the second line.

Is IFort treating a hidden argument because c_ptr is a derived type?

Since both Fortran compilers have to cooperate with GCC, should they not pass the same number of arguments?

Similar problems occur with IFort 12.0.3 (IA32). The assembly produced is

[bash]             mov    0x4(%esp),%eax
mov 0x8(%esp),%edx
mov %edx,(%eax)
ret
[/bash]
where the second and third lines, I think, should not be there.

With the 32- and 64-bit compilers, then, not only is the C-pointer returned as the function result (as intended), but the target of that pointer also gets modified using a full-word item on the stack that was not placed there by the C-caller, resulting in unpredictable results.
0 Kudos
9 Replies
Steven_L_Intel1
Employee
1,202 Views
We're looking at this - there should not be a second argument. I'm not convinced yet that that is what you're seeing there, but it is fishy.
0 Kudos
pbkenned1
Employee
1,202 Views
I've reproduced the issue on Linux and Mac OS X, with both the IA-32 and Intel64 compilers, versions 11.1 and 12.0. I'll file a bug report and post the issue ID shortly. Windows does not appear to be affected.

Patrick Kennedy
Intel Developer Support
0 Kudos
pbkenned1
Employee
1,202 Views
The defect tracking number for this issue is DPD200169281. I'll keep this thread updated with the progress to repair.

Patrick Kennedy
0 Kudos
Udit_P_Intel
Employee
1,202 Views
I believe the issue you report here is similar to another thread ( http://software.intel.com/en-us/forums/showthread.php?t=79419 ) Both seem to exhibit similar symptoms.

Best!
-Udit
0 Kudos
mecej4
Honored Contributor III
1,202 Views
The two may be related but there are these dissimilarities:

1. The Windows versions, 11.1 and 12.0, are not affected by the error reported here. The other thread was about bugs in the Windows version 12.0 only.

2. The error in the other thread involved an incorrect RET nn instruction, the present one does not.
0 Kudos
Steven_L_Intel1
Employee
1,202 Views
The cause of this and related issues has been found and fixed. The fix won't be in Update 4 but I think it will be in Update 5. The compiler was not properly dealing with a function result for a BIND(C) function.
0 Kudos
dasmy
Beginner
1,202 Views
Thank you mecej4, Patrick and Steve for elaborating and solving the issue.

I am looking forward to that update for solving my original problem in http://software.intel.com/en-us/forums/showthread.php?t=82500 .

Best Regards,

Mathias
0 Kudos
Udit_P_Intel
Employee
1,202 Views
Yes, I just checked that your original symptom also seems to have been addressed by this compiler change.
Best!
-Udit
0 Kudos
pbkenned1
Employee
1,202 Views
DPD200169281 is fixed in Composer XE update #6 (aka, the 12.1 compiler). The Linux* and Mac OS X* packages containing the fixes are:

l_fcompxe_2011.6.233.tgz (Linux)
m_fcompxe_2011.6.038.dmg (Mac OS X)

Patrick
0 Kudos
Reply