- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Attached is an example
under debugger, it seems possibly that arguments passed from C by 'value' to the .f90 function are being forwarded directly into the .f function, which expects everything 'by ref', of course.
i mean ... this is serious, for out group, moving forward.
does anyone know how to raise this issue 'officially' with Intel?
-Winston
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In your exa1.c you have two prototypes for f_nop_of_int. I do not think that is an issue.
I see that your build instructions include the option -fPIC.
This may be the source of the issue. Are you able to compile this test program without -fPIC to see if the problem is related to this option?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My bad (double pasted sample into exa1.c);
updated
without -fPIC
~/opt0101/OPT/SNOPT/snopt7/makes$ exmake;./exa
icx -ipo -O0 -c exa1.c
ifx -ipo -O0 -c exa2.f
ifx -ipo -O0 -c exa3.f90 -I /apps/intel/oneapi-2023/compiler/latest/linux/compiler/include/intel64/
ifx -ipo -O0 exa2.o exa3.o -shared -o exaso.so
icx -ipo -O0 exa1.o -L. -l:exaso.so -o exa
Segmentation fault
Thanks for replying!
I do believe it is an error in either the compilation of the .f90 file, or linking (less likely)
Recall exa3.f90:
module nop_c_interop
use iso_c_binding
implicit none
external :: nop_of_int
public :: f_nop_of_int
contains
subroutine f_nop_of_int (i1, i2, i3, iarray) bind(C,name="f_nop_of_int")
integer(c_int), intent(in), value :: i1,i2,i3
integer(c_int), intent(inout) :: iarray(i3)
call nop_of_int(i1, i2, i3, iarray)
end subroutine f_nop_of_int
end module nop_c_interop
When i use gdb to look at the stack frame set up at the very beginning of the 'regular fortran' function being called (nop_of_int), then, instead of the addresses of 'i1,i2,i3', what i see on the stack are the values of 'i1,i2,i3'.
Obviously, if i remove the 'value' designator from the f90 code, above, for function (f_nop_of_int), then addresses get passed to 'nop_of_int'.
However, the C-function is declared, implement as take values -- so that would all have to be changed.
FYI, the ifort compiler has no problem making this all work.
Perhaps Intel will say, the 'value' keyword is no long supported in F90 in this way.
Do you happen to know the people/department to contact about this ... language issue, i guess.
Thanks again for the suggestion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>Perhaps Intel will say, the 'value' keyword is no long supported in F90 in this way.
Ahh, this is something I think Steve Lionel may be able to shed some light on.
I am going to make an unfounded statement.
In exa3.f90 you have:
external :: nop_of_int
as opposed to using (declaring) an interface.
Try replacing the above statement with:
interface
subroutine nop_of_int( i1, i2, i3, iarray)
implicit none
integer i1,i2,i3
end subroutine nop_of_int
end interface
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OOPS
add
integer :: iarray(i3)
to the interface
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks!!
this modification caused the segfault to disappear (i.e. for the argument to be 'passed by address' into the receiving function)
Were this my project, it is definitely how i would have coded it (makes sense from the perspective of C/++ type languages)
Thank you very much, again!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In a call to a procedure (function or subroutine), one or more actual arguments may have a corresponding dummy argument that has the attribute VALUE. Please be aware that such a call is not really the same as a procedure-call-by-value-argument as implemented in languages such as Algol, Pascal, C, Java, etc.
The Fortran Standard says,
If the dummy argument has the VALUE attribute it becomes associated with a definable anonymous
data object whose initial value is that of the actual argument. Subsequent changes to the value or
definition status of the dummy argument do not affect the actual argument.
In addition, the argument passing convention may be modified by visible interfaces, embedded compiler directives in the source code, and compiler options.
Therefore, what is passed on the stack may be a combination of (1) the address of an actual argument, (2) the address of an anonymous variable whose value is the same as that of the actual argument, (3) the value of the argument.
Is the symbolic debugger that you are using capable of handling all these combinations correctly and provide you correct information on the values of dummy arguments? Are you using the correct debugger settings to enable the correct information to be displayed? Are you interpreting the debugger displays correctly?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To add to what @mecej4 said, the Fortran VALUE attribute DOES mean pass-by-value, in the C sense, only when the procedure being called has the BIND(C) attribute. I have not looked at your example to see if that's the reason for the problem.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page