using icx/ifx to compile/link files *.c <-> *.f90 <-> *.f with -O0 produces SEGFAULT

[Churchill]

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

[jimdempseyatthecove]

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

[Churchill]

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.

[jimdempseyatthecove]

>>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

[jimdempseyatthecove · Accepted solution]

OOPS

add

integer :: iarray(i3)

to the interface

Jim Dempsey

[Churchill]

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!!

[mecej4]

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?

[Steve_Lionel]

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.