problem between c++ and fortran memory boundary

[NM]

Hi All,
I am having a peculiar problem. I used to link between intel fortran 7.0
and g++ without any problem. Now the intel compiler is upgraded to version
9.0 and I am getting segmenatation fault. While debugging I found when data
structures are allocated in C++ and passed to fortran subroutines the
fortran subroutines are accessing a different location in the address space.
For example I have created a very simple program that shows the problem

The fortran subroutine in the file b.f
subroutine fortran_sub(MAXNODS,NODES)

type node
integer :: order
integer :: father
integer :: sons(3)
double precision :: zdofs(10)
endtype node

type(node) ::NODES(MAXNODS)
integer MAXNODS,i

do i = 1 , MAXNODS
NODES(i)%order = i
NODES(i)%father = i
enddo

return
end

The C++ main function in a.cpp
#include <iostream>

using namespace std;

class node_contiguous_struct {
public:
int order;
int father;
int sons[3];
double zdofs[10];
};
typedef node_contiguous_struct * node_array_contiguous;

extern "C" {
void fortran_sub_(int *MAXNODS,node_array_contiguous NODES);
}

int main(void)
{
node_array_contiguous NODES;
int MAXNODS = 5;

NODES = new node_contiguous_struct[MAXNODS];
fortran_sub_(&MAXNODS,NODES);

for (int i = 0; i < MAXNODS; i++) {
cout << "\nNODES["<<i<<"]\n";
cout << " .order = " << NODES[i].order;
cout << " .father = " << NODES[i].father;
}
return 0;
}
and the output of the program

NODES[0]
.order = 1 .father = 1
NODES[1]
.order = 0 .father = 2
NODES[2]
.order = 0 .father = 0
NODES[3]
.order = 0 .father = 0
NODES[4]
.order = 0 .father = 0

Obviously the fortran subroutine is writing somewhere else in the memory
space, thus after the first index everything is messed up. I did not had
this problem with intel fortran compiler version 7. Can this be a compiler
specific problem? Am I doing something wrong here?

Any help is appreciated.

Thanks

NM

[Jan Vorbrüggen]

There is no guarantee that the compiler will not rearrange the order of
the members of a derived type. I believe this is so even for SEQUENCE
types, but it's certainly allowed for non-SEQUENCE types, as in your
case. It is likely that this optimization is performed because your
definition is not in natural order - that is, have all members in the
reverse order of size.

Try putting the double precision array first and see whether the error
goes away.

This is one of the things only F03 can fix permanently and portably.
But a rule as the one above increases your chances things will work
properly now.

Jan

[NM]

Thanks a lot for your input.

But it did not solve the problem. The order I tried was in the order of
zdofs,sons,order and father in both C++ and fortran.

Thanks
"Jan Vorbrüggen" <jv**************@mediasec.de> wrote in message
news:3o************@individual.net...

There is no guarantee that the compiler will not rearrange the order of
the members of a derived type. I believe this is so even for SEQUENCE
types, but it's certainly allowed for non-SEQUENCE types, as in your
case. It is likely that this optimization is performed because your
definition is not in natural order - that is, have all members in the
reverse order of size.

Try putting the double precision array first and see whether the error
goes away.

This is one of the things only F03 can fix permanently and portably.
But a rule as the one above increases your chances things will work
properly now.

Jan

[Jan Vorbrüggen]

Put some signature values into each member, and then see what order they
are in on the Fortran side.

Does the compiler offer a listing which might provide information on the
layout of the types? Or perhaps a machine-code listing for a very simple
sample? One should be able to deduce actual layout from that easily.

Jan

[E. Robert Tisdale]

NM wrote:

I am having a peculiar problem.
I used to link between intel fortran 7.0 and g++ without any problem.
Now the intel compiler is upgraded to version 9.0
and I am getting segmenatation fault. While debugging I found [that],
when data structures are allocated in C++ and passed to Fortran subroutines,
the Fortran subroutines are accessing a different location in the address space.
For example I have created a very simple program that shows the [solution]: cat b.f90 subroutine fortran_sub(nodes, p)

type node_t
sequence
integer :: order
integer :: father
integer :: sons(3)
double precision :: zdofs(10)
end type node_t

integer, intent(in):: nodes
type(node_t), intent(inout):: p(nodes)
integer node

do node = 1, nodes
p(node)%order = node
p(node)%father = node
end do

return
end subroutine fortran_sub
ifort -c b.f90 fortcom: Warning: b.f90, line 3: \
The structure contains one or more misaligned fields. [NODE_T]
type node_t
-----------^ cat a.cpp #include <iostream>

class node_contiguous_struct {
public:
int order;
int father;
int sons[3];
double zdofs[10];
};

extern "C" {
void fortran_sub_(const int& nodes,
node_contiguous_struct p[]);
}

int main(int argc, char* argv[]) {
const
int nodes = 5;
node_contiguous_struct*
p = new node_contiguous_struct[nodes];
fortran_sub_(nodes, p);

for (int node = 0; node < nodes; ++node) {
std::cout << "p[" << node << "]" << std::endl;
std::cout << " .order = " << p[node].order;
std::cout << " .father = " << p[node].father;
std::cout << std::endl;
}
return 0;
}
g++ -Wall -ansi -pedantic a.cpp b.o
a.out

p[0]
.order = 1 .father = 1
p[1]
.order = 2 .father = 2
p[2]
.order = 3 .father = 3
p[3]
.order = 4 .father = 4
p[4]
.order = 5 .father = 5

Always use the sequence keyword in your derived type definition
if you need to access data members from C or C++.
Notice also that I used a const reference
to pass the number of nodes to fortran_sub_.

[NM]

Thanks a lot. It solved the problem.

NM
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:df**********@nntp1.jpl.nasa.gov...

NM wrote:

I am having a peculiar problem.
I used to link between intel fortran 7.0 and g++ without any problem.
Now the intel compiler is upgraded to version 9.0
and I am getting segmenatation fault. While debugging I found [that],
when data structures are allocated in C++ and passed to Fortran
subroutines,
the Fortran subroutines are accessing a different location in the address
space. For example I have created a very simple program that shows the
[solution]:

> cat b.f90

subroutine fortran_sub(nodes, p)

type node_t
sequence
integer :: order
integer :: father
integer :: sons(3)
double precision :: zdofs(10)
end type node_t

integer, intent(in):: nodes
type(node_t), intent(inout):: p(nodes)
integer node

do node = 1, nodes
p(node)%order = node
p(node)%father = node
end do

return
end subroutine fortran_sub

> ifort -c b.f90

fortcom: Warning: b.f90, line 3: \
The structure contains one or more misaligned fields. [NODE_T]
type node_t
-----------^

> cat a.cpp

#include <iostream>

class node_contiguous_struct {
public:
int order;
int father;
int sons[3];
double zdofs[10];
};

extern "C" {
void fortran_sub_(const int& nodes,
node_contiguous_struct p[]);
}

int main(int argc, char* argv[]) {
const
int nodes = 5;
node_contiguous_struct*
p = new node_contiguous_struct[nodes];
fortran_sub_(nodes, p);

for (int node = 0; node < nodes; ++node) {
std::cout << "p[" << node << "]" << std::endl;
std::cout << " .order = " << p[node].order;
std::cout << " .father = " << p[node].father;
std::cout << std::endl;
}
return 0;
}

> g++ -Wall -ansi -pedantic a.cpp b.o
> a.out

p[0]
.order = 1 .father = 1
p[1]
.order = 2 .father = 2
p[2]
.order = 3 .father = 3
p[3]
.order = 4 .father = 4
p[4]
.order = 5 .father = 5

Always use the sequence keyword in your derived type definition
if you need to access data members from C or C++.
Notice also that I used a const reference
to pass the number of nodes to fortran_sub_.