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
名誉コントリビューター III
1,200件の閲覧回数
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 件の賞賛
9 返答(返信)
Steven_L_Intel1
従業員
1,200件の閲覧回数
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.
pbkenned1
従業員
1,200件の閲覧回数
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
pbkenned1
従業員
1,200件の閲覧回数
The defect tracking number for this issue is DPD200169281. I'll keep this thread updated with the progress to repair.

Patrick Kennedy
Udit_P_Intel
従業員
1,200件の閲覧回数
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
mecej4
名誉コントリビューター III
1,200件の閲覧回数
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.
Steven_L_Intel1
従業員
1,200件の閲覧回数
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.
dasmy
ビギナー
1,200件の閲覧回数
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
Udit_P_Intel
従業員
1,200件の閲覧回数
Yes, I just checked that your original symptom also seems to have been addressed by this compiler change.
Best!
-Udit
pbkenned1
従業員
1,200件の閲覧回数
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
返信