Hi Jeff
This is a Mac OS X (10.5.7) specific issue, that occurs for all
versions > 1.2.9 that I've tested (1.3.0 through the 1.4 nightly),
regardless of what fortran compiler you use (ifort / g95 / gfortran).
I've been able to replicate this issue on other OS X machines, and I
am sure that I am using the correct headers / libraries. Version 1.2.9
is working correctly. Here are some system details:
$ uname -a
Darwin zamblap.epp.ist.utl.pt 9.7.0 Darwin Kernel Version 9.7.0: Tue
Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
This might be a (again, Mac OS X specific) libtool issue. If you look
at the name list of the generated .dylib libraries for 1.3.3 you get:
$ nm /opt/openmpi/1.3.3-g95-32/lib/*.dylib | grep -i in_place
000a4d30 S _MPI_FORTRAN_IN_PLACE
000a4d34 S _mpi_fortran_in_place
000a4d38 S _mpi_fortran_in_place_
000a4d3c S _mpi_fortran_in_place__
000a4d30 S _MPI_FORTRAN_IN_PLACE
000a4d34 S _mpi_fortran_in_place
000a4d38 S _mpi_fortran_in_place_
000a4d3c S _mpi_fortran_in_place__
00007328 S __ZN3MPI8IN_PLACEE
00007328 S __ZN3MPI8IN_PLACEE
U _mpi_fortran_in_place__
U _mpi_fortran_in_place__
00036eea D _orte_snapc_base_store_in_place
00036eea D _orte_snapc_base_store_in_place
But for 1.2.9 you get:
$ nm /opt/openmpi/1.2.9-g95-32/lib/*.dylib | grep -i in_place
00093950 S _MPI_FORTRAN_IN_PLACE
00093954 S _mpi_fortran_in_place
00093958 S _mpi_fortran_in_place_
0009395c S _mpi_fortran_in_place__
00093950 S _MPI_FORTRAN_IN_PLACE
00093954 S _mpi_fortran_in_place
00093958 S _mpi_fortran_in_place_
0009395c S _mpi_fortran_in_place__
0000e00c D __ZN3MPI8IN_PLACEE
0000e00c D __ZN3MPI8IN_PLACEE
U _mpi_fortran_in_place__
U _mpi_fortran_in_place__
So the __ZN3MPI8IN_PLACEE symbol, that I guess refers to the Fortran
MPI_IN_PLACE constant is being defined incorrectly in the 1.3.3
version as a S (symbol in a section other than those above), while it
should be defined as a D (data section symbol) as part of an
"external" common block, as it happens in 1.2.9. So when linking the
1.3.3 version the MPI_IN_PLACE constant will never have the same
address as any of the mpi_fortran_in_place variables, but rather its
own address.
Thanks again for your help,
Ricardo
---
Prof. Ricardo Fonseca
GoLP - Grupo de Lasers e Plasmas
Instituto de Plasmas e Fusão Nuclear
Instituto Superior Técnico
Av. Rovisco Pais
1049-001 Lisboa
Portugal
tel: +351 21 8419202
fax: +351 21 8464455
web: http://cfp.ist.utl.pt/golp/
On Aug 1, 2009, at 17:00 , users-requ...@open-mpi.org wrote:
Message: 2
Date: Sat, 1 Aug 2009 07:44:47 -0400
From: Jeff Squyres <jsquy...@cisco.com>
Subject: Re: [OMPI users] OMPI users] MPI_IN_PLACE in Fortran
withMPI_REDUCE / MPI_ALLREDUCE
To: Open MPI Users <us...@open-mpi.org>
Message-ID: <ca25ccf4-c5e7-47c0-a24e-8b05b59a6...@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hmm. FWIW, I'm unable to replicate your error. I tried with the OMPI
SVN trunk and a build of the OMPI 1.3.3 tarball using the GNU compiler
suite on RHEL4U5.
I've even compiled your sample code with "mpif90" using the "use mpi"
statement -- I did not get an unclassifiable statement. What version
of Open MPI are you using? Please sent the info listed here:
http://www.open-mpi.org/community/help/
Can you confirm that you're not accidentally mixing and matching
multiple versions of Open MPI?
