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

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