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-request@open-mpi.org wrote:

Message: 2
Date: Sat, 1 Aug 2009 07:44:47 -0400
From: Jeff Squyres <jsquyres@cisco.com>
Subject: Re: [OMPI users] OMPI users] MPI_IN_PLACE in Fortran
withMPI_REDUCE / MPI_ALLREDUCE
To: Open MPI Users <users@open-mpi.org>
Message-ID: <CA25CCF4-C5E7-47C0-A24E-8B05B59A6474@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?