[OMPI devel] openMPI 1.4.2: mpi_write fails on NFSv3 crossmounts

[Oliver Deppert]

General informations:

3 node Opteron cluster, 24CPUs, Melanox Infiniband 10Gb interconnect
Debian Lenny 5.0
self build kernel from kernel.org: 2.6.32.12, all NFS functions 
available from kernel side
self build NFS-utils 1.2.2 from debian source of sid: nfs-kernel-server, 
nfs-common


nfs-server with working lockd
fnctl() and locking is available on all nfs-clients, tested with 
perl-script (attached)


openMPI 1.4.2 (build with GNU 4.3.2)
configure options:
./configure --prefix=/opt/openMPI_gnu_4.3.2 --sysconfdir=/etc 
--localstatedir=/var --with-libnuma=/usr --with-libnuma-libdir=/usr/lib 
--enable-mpirun-prefix-by-default --enable-sparse-groups --enable-static 
--enable-cxx-exceptions --with-wrapper-cflags='-O3 -march=opteron' 
--with-wrapper-cxxflags='-O3 -march=opteron' --with-wrapper-fflags='-O3 
-march=opteron' --with-wrapper-fcflags='-O3 -march=opteron' 
--with-openib --with-gnu-ld CFLAGS='-O3 -march=opteron' CXXFLAGS='-O3 
-march=opteron' FFLAGS='-O3 -march=opteron' FCFLAGS='-O3 -march=opteron'


===

Dear openMPI developers,

I've found a bug in the current stable release of openMPI 1.4.2 which is 
related to the MPI_WRITE function in combination with the execution on a 
NFS-v3-crossmount. I've attached a small Fortran code-snip (testmpi.f), 
which uses mpi_write to create a file "test.dat" which contains 
{1,2,3,4,5,6} in binary, MPI_REALS written from every mpi-node executed 
on, in the right displacement to every node.


When I execute this code on a glusterFS share, everthing works like a 
charmeno problems at all


The Problem is, when I try to compile and execute this program for two 
nodes on an NFS-crossmount with openMPI, I get the following MPI error:

[ppclus02:23440] *** An error occurred in MPI_Bcast
[ppclus02:23440] *** on communicator MPI COMMUNICATOR 3 DUP FROM 0
[ppclus02:23440] *** MPI_ERR_TRUNCATE: message truncated
[ppclus02:23440] *** MPI_ERRORS_ARE_FATAL (your MPI job will now abort)
--
mpiexec has exited due to process rank 1 with PID 23440 on
node 192.168.11.2 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpiexec (as reported here).
--

My first educated guess was, that my NFS-crossmounts aren't capable to 
make use of fnct() to lock the file needed by MPI_WRITE. So, i gave a 
try on the following perl script (lock.pl). The result was: fnctl() and 
NFS-file-locking works...


In comparison, I also tried the recent unstable version of MPICH2 v1.3a2 
on the same NFS-crossmount. With MPICH2 it works also without any 
problems on NFS-v3.


Thanks for your help, I remain in

best regards,
Oliver Deppert


lock.pl (to test NFS fnctl()-file locking)
-

#!/usr/bin/perl
 use Fcntl;
 open FH, ">locktest.lock" or die "Cannot open $fn: $!";
 print "Testing fcntl...\n";
 @list = (F_WRLCK,0,0,0,0); # exclusive write lock, entire file
 $struct = pack("SSLLL",@list);
 fcntl(FH,&F_SETLKW,$struct) or die("cannot lock because: $!\n");

--

testmpi.f (fortran 90 code-snip to test mpi_write on NFS-v3)
-
  program WRITE_FILE

  implicit none
  include 'mpif.h'

  integer info,pec
  integer npe,mpe,mtag

  integer :: realsize,file,displace,displaceloc
  integer(kind=MPI_OFFSET_KIND) :: disp
  integer :: status(MPI_STATUS_SIZE)
  real(kind=4) :: locidx(6)


c INITIALIZATION

  call MPI_INIT(info)
  call MPI_COMM_SIZE(MPI_COMM_WORLD,npe,info)  call 
MPI_COMM_RANK(MPI_COMM_WORLD,mpe,info)



c routine

  mtag=123
  displace=6

  !send data offset
  do pec=0,mpe-1
 CALL MPI_SEND(displace,1,MPI_INTEGER,
&   pec,mtag,MPI_COMM_WORLD,info)
  enddo
  do pec=mpe+1,npe-1
 CALL MPI_SEND(displace,1,MPI_INTEGER,
&   pec,mtag,MPI_COMM_WORLD,info)
  enddo

  displaceloc=0
  !get data offset
  do pec=0,mpe-1
 CALL MPI_RECV(displace,1,MPI_INTEGER,pec,mtag,
&MPI_COMM_WORLD,status,info)

 displaceloc=displaceloc+displace
  enddo

  CALL MPI_TYPE_EXTENT(MPI_REAL,realsize,info)
  disp=displaceloc*realsize

  !open file
  CALL MPI_FILE_OPEN(MPI_COMM_WORLD,'test.dat',
&   MPI_MODE_WRONLY+MPI_MODE_CREATE,MPI_INFO_NULL,file,info)

  !set file view (displaceme

Re: [OMPI devel] 1.5rc5 has been posted

[Paul H. Hargrove]

I have access to PGI compilers 10.{3,4,5,8} on an Opteron/InifiniBand 
cluster running Scientific Linux 5.4 (an RHEL derivative like the Centos 
distro).  I can try to reproduce Larry Baker's problems today with the 
most recent 10.8 compiler.  If there are other things I could/should be 
trying to complement or confirm Larry's findings, let me know.


-Paul

Larry Baker wrote:

OpenMPI 1.5rc5 make fails for the PGI 10.3 compilers:

make[2]: Entering directory 
`/home/baker/openmpi-1.5rc5/opal/tools/wrappers'

  CC opal_wrapper.o
  CCLD   opal_wrapper
../../../opal/.libs/libopen-pal.so: undefined reference to 
`pthread_create'

../../../opal/.libs/libopen-pal.so: undefined reference to `assert'
../../../opal/.libs/libopen-pal.so: undefined reference to 
`pthread_mutex_trylock'
../../../opal/.libs/libopen-pal.so: undefined reference to 
`pthread_atfork'

../../../opal/.libs/libopen-pal.so: undefined reference to `pthread_join'
make[2]: *** [opal_wrapper] Error 2
make[2]: Leaving directory 
`/home/baker/openmpi-1.5rc5/opal/tools/wrappers'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/baker/openmpi-1.5rc5/opal'
make: *** [all-recursive] Error 1

I have not had time yet to track this down.  I am at a conference 
today and tomorrow, so I might not have time to look into this until 
Wednesday.


I configured OpenMPI with:

[baker@hydra openmpi-1.5rc5]$ ./configure >configure.log 2>&1
--prefix=/opt/pgi/linux86-64/10.3/openmpi-1.5rc5 --with-sge
--with-wrapper-cflags="-DNO_PGI_OFFSET"
--with-wrapper-cxxflags="-DNO_PGI_OFFSET"CC="pgcc -m64"
CFLAGS="-g -fast -tp amd64 -DNO_PGI_OFFSET"CXX="pgcpp -m64"
CXXFLAGS="-g -fast -tp amd64 -DNO_PGI_OFFSET"FC="pgf90 -m64"
FCFLAGS="-g -fast -tp amd64"F77="pgf90 -m64"FFLAGS="-g -fast 
-tp amd64"


The O/S is CentOS 4.5 Linux x86_64:

[baker@hydra ~]$ cat /etc/redhat-release CentOS release 4.5 (Final)
[baker@hydra ~]$ uname -a
Linux hydra.wr.usgs.gov 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 26 14:14:47 
EDT 2007 x86_64 x86_64 x86_64 GNU/Linux


Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov

On Aug 17, 2010, at 2:18 PM, Jeff Squyres wrote:


We still have one known possible regression:

https://svn.open-mpi.org/trac/ompi/ticket/2530

But we posted rc5 anyway (there's a bunch of stuff that has been 
pending for a while that is now in).  Please test!


http://www.open-mpi.org/software/ompi/v1.5/

--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] Refactoring opal if.c

[Ralph Castain]

Per the discussion on today's telecon, I've started working with Jeff on 
refactoring the opal/util/if.c code into something more understandable without 
changing the discovery logic. We are creating a framework that solely performs 
interface discovery, leaving all of the interface wrapper functions untouched. 
The various components are now configured in/out instead of being buried in 
multiple layers of #if.

Jeff will be working on the configure logic in the near future. Meantime, the 
layout of the system is complete and everything builds as it should.

Operation of the framework is straightforward. When framework open is called, 
it iterates through all available components and calls their open function. At 
that time, each component adds to the list of interfaces whatever it finds. The 
IPv4 interface discovery that was common across posix-based systems is located 
in a single component. The IPv6 discovery code, which tended to be highly 
system specific, is in separate components.

As a result, there may be a change in the order in which interfaces are found 
on the list from where they appear today. However, this order was never 
guaranteed anyway, so any code that relied on it is incorrect and should be 
fixed.

You are welcome to look at what is being done:

hg clone https://r...@bitbucket.org/rhc/ompi-if

Ralph

Re: [OMPI devel] Refactoring opal if.c

[Jeff Squyres]

More specifically: if.h has not been changed (except for its finalize function).

So all this change does it un-spaghettify the if.c code.  From an interface 
perspective, the rest of the code base isn't even aware that this change 
occurred.

Also, I think Ralph meant the following URL:

https://bitbucket.org/rhc/ompi-if




On Aug 24, 2010, at 5:11 PM, Ralph Castain wrote:

> Per the discussion on today's telecon, I've started working with Jeff on 
> refactoring the opal/util/if.c code into something more understandable 
> without changing the discovery logic. We are creating a framework that solely 
> performs interface discovery, leaving all of the interface wrapper functions 
> untouched. The various components are now configured in/out instead of being 
> buried in multiple layers of #if.
> 
> Jeff will be working on the configure logic in the near future. Meantime, the 
> layout of the system is complete and everything builds as it should.
> 
> Operation of the framework is straightforward. When framework open is called, 
> it iterates through all available components and calls their open function. 
> At that time, each component adds to the list of interfaces whatever it 
> finds. The IPv4 interface discovery that was common across posix-based 
> systems is located in a single component. The IPv6 discovery code, which 
> tended to be highly system specific, is in separate components.
> 
> As a result, there may be a change in the order in which interfaces are found 
> on the list from where they appear today. However, this order was never 
> guaranteed anyway, so any code that relied on it is incorrect and should be 
> fixed.
> 
> You are welcome to look at what is being done:
> 
> hg clone https://r...@bitbucket.org/rhc/ompi-if
> 
> Ralph
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] A different 1.5rc5 build failure w/ PGI compilers

[Paul H. Hargrove]

I went to try to reproduce the problem Larry Baker reported w/ the PGI 
10.3 compilers and undefined references in libopen-pal.so when linking 
opal_wrapper.  Instead I encountered a different error that does not (as 
best I can tell) correspond to any of the issues Larry has reported 
recently.  Once I disable the error-inducing VT code, I am unable to 
reproduce Larry's problem with the 10.3, 10.5 or 10.8 PGI compilers.


My system and the errors:

$ cat /etc/redhat-release
Scientific Linux SL release 5.4 (Boron)

$ uname -a
Linux cvrsvc01 2.6.18-164.9.1.el5c-perf #1 SMP Wed Jun 9 14:40:25 PDT 
2010 x86_64 x86_64 x86_64 GNU/Linux


$ /lib64/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
Compiled on a Linux 2.6.9 system on 2009-09-02.
Available extensions:
   The C stubs add-on version 2.1.2.
   crypt add-on version 2.1 by Michael Glad and others
   GNU Libidn by Simon Josefsson
   GNU libio by Per Bothner
   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
   Native POSIX Threads Library by Ulrich Drepper et al
   BIND-8.2.3-T5B
   RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
.

$ pgcc -V  
pgcc 10.5-0 64-bit target on x86-64 Linux -tp nehalem-64

Copyright 1989-2000, The Portland Group, Inc.  All Rights Reserved.
Copyright 2000-2010, STMicroelectronics, Inc.  All Rights Reserved.

$ [path_to]/openmpi-1.5rc5/configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf90
[...]

$ make
[...]
make[9]: Entering directory 
`/global/scratch/sd/hargrove/ompi-1.5rc5-pgi-10.5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile'

 CXXotfprofile-otfprofile.o
"/global/common/carver/usg/pgi/10.5/linux86-64/10.5/include/omp.h", line 
41: error:

 expected an identifier
 extern int omp_get_thread_num(void);
^

"/global/common/carver/usg/pgi/10.5/linux86-64/10.5/include/omp.h", line 
43: error:

 expected an identifier
 extern int omp_get_num_threads(void);
^

"../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp", 
line 572: error:

 this kind of pragma may not be used here
 # pragma omp barrier
  ^

"../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp", 
line 607: error:

 this kind of pragma may not be used here
 # pragma omp barrier
  ^

"../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp", 
line 648: error:

 this kind of pragma may not be used here
 # pragma omp barrier
  ^

5 errors detected in the compilation of 
"../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp".

[...]

It appears that the source file in question ALREADY contains a 
work-around for this issue:
/* Disable OpenMP if the PGI compiler is used to work around the 
following errors:


compiler version  compiler error
< 9.0-3   PGCC-S--Internal compiler error. calc_dw_tag:no tag
(see Technical Problem Report 4337 at 
http://www.pgroup.com/support/release_tprs_90.htm)


10.1 - 10.6   this kind of pragma may not be used here
  #pargma omp barrier
*/
#if defined(_OPENMP) && defined(__PGI)
#   undef _OPENMP
#endif


#ifdef _OPENMP
#   include 
#else
#   define omp_get_thread_num() 0
#   define omp_get_num_threads() 1
#endif


However, it appears that the C++ STL headers (included via Summary.h) 
are indirectly including omp.h, leading to this failure: the "expected 
an identifier" due to the two #defines in the work-around, and the "this 
kind of pragma..." errors due to the original issue resurfacing.


I have reproduced this problem with PGI versions 10.3, 10.5 and 10.8.

If I configure with --disable-vt then I (obviously) don't encounter this 
error.  In that case I am able to complete the build of 1.5rc5 with no 
errors.  This means an INABILITY to reproduce Larry's undefined 
references problem.


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] 1.4.3rc1 out

[Ralph Castain]

Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
give it a whirl.

http://www.open-mpi.org/software/ompi/v1.4/

Ralph

Re: [OMPI devel] 1.4.3rc1 out

[Paul H. Hargrove]

With PGI-10.5 I see the same 4 warnings in atomic.h that Jeff reported 
in June with PGI-7.0.7

http://www.open-mpi.org/community/lists/devel/2010/06/8060.php

Other than that, I can report a clean build w/ PGI-10.5.
I will try 10.8 next, but will only report to the list only if there are 
problems.


-Paul


Ralph Castain wrote:

Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
give it a whirl.

http://www.open-mpi.org/software/ompi/v1.4/

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] 1.5rc5 build failure with icc-11.1

[Paul H. Hargrove]

Trying to build 1.5rc5 with icc-11.1.046 is failing in otfprofile.cpp - 
the same file I saw problems with when using the PGI compilers.


$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2

$  uname -a
Linux jaguar-ext3 2.6.16.60-0.42.7-smp #1 SMP Tue Nov 3 11:20:42 UTC 
2009 x86_64 x86_64 x86_64 GNU/Linux


$ /lib64/libc.so.6
GNU C Library stable release version 2.4 (20091027), by Roland McGrath 
et al.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for x86_64-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2009-10-27.
Available extensions:
   crypt add-on version 2.1 by Michael Glad and others
   GNU Libidn by Simon Josefsson
   GNU libio by Per Bothner
   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
   Native POSIX Threads Library by Ulrich Drepper et al
   BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

$ icc --version
icc (ICC) 11.1 20090630
Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.

$[path_to]/openmpi-1.5rc5/configure CC=icc CXX=icpc F77=ifort FC=ifort
[...]

$make
[...]
Making all in otfprofile
make[9]: Entering directory 
`/lustre/widow1/scratch/hargrove/ompi-1.5rc5-icc-11.1.046/ompi/contrib/vt/vt/extli

b/otf/tools/otfprofile'
 CXXotfprofile-otfprofile.o
../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp(25): 
c

atastrophic error: could not open source file "omp.h"
 # include 
  ^

compilation aborted for 
../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofi

le/otfprofile.cpp (code 4)
[...]


If I configure with --disable-vt then I get a complete build.

There are numerous instances of ICC's
   warning #188: enumerated type mixed with another type
which I personally don't consider to be a serious issue.

Other than the 188's, there is only one other compiler warning seen:
/bin/sh ./libtool  --tag=CC   --mode=compile icc -DHAVE_CONFIG_H -I. 
-I../../../openmpi-1.5rc5/opal/libltdl  -DLTDLOPEN=libltdlc 
-DLT_CONFIG_H='' -DLTDL -I. 
-I../../../openmpi-1.5rc5/opal/libltdl -Ilibltdl 
-I../../../openmpi-1.5rc5/opal/libltdl/libltdl 
-I../../../openmpi-1.5rc5/opal/libltdl/libltdl   -O3 -DNDEBUG   
-fvisibility=hidden -MT libltdlc_la-ltdl.lo -MD -MP -MF 
.deps/libltdlc_la-ltdl.Tpo -c -o libltdlc_la-ltdl.lo `test -f 'ltdl.c' 
|| echo '../../../openmpi-1.5rc5/opal/libltdl/'`ltdl.c
libtool: compile:  icc -DHAVE_CONFIG_H -I. 
-I../../../openmpi-1.5rc5/opal/libltdl -DLTDLOPEN=libltdlc 
"-DLT_CONFIG_H=" -DLTDL -I. 
-I../../../openmpi-1.5rc5/opal/libltdl -Ilibltdl 
-I../../../openmpi-1.5rc5/opal/libltdl/libltdl 
-I../../../openmpi-1.5rc5/opal/libltdl/libltdl -O3 -DNDEBUG 
-fvisibility=hidden -MT libltdlc_la-ltdl.lo -MD -MP -MF 
.deps/libltdlc_la-ltdl.Tpo -c 
../../../openmpi-1.5rc5/opal/libltdl/ltdl.c -o libltdlc_la-ltdl.o
../../../openmpi-1.5rc5/opal/libltdl/ltdl.c(1268): warning #279: 
controlling expression is constant
  archive_name = MALLOC (char, LT_STRLEN (name) + LT_STRLEN 
(libext) + 2);

 ^


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.4.3rc1 out

[Paul H. Hargrove]

Building w/ icc-11.1.046 on x86-64 works with some warnings.

In addition to the numerous "188" warnings and the single instance of 
"279" that I reported seeing for 1.5rc5 
(http://www.open-mpi.org/community/lists/devel/2010/08/8320.php), there 
is one additional warning:
libtool: compile:  icc -DHAVE_CONFIG_H -I. 
-I../../../openmpi-1.4.3rc1/ompi/datatype -I../../opal/include 
-I../../orte/include -I../../ompi/include 
-I../../opal/mca/paffinity/linux/plpa/src/libplpa 
-I../../../openmpi-1.4.3rc1 -I../.. 
-I../../../openmpi-1.4.3rc1/opal/include 
-I../../../openmpi-1.4.3rc1/orte/include 
-I../../../openmpi-1.4.3rc1/ompi/include -O3 -DNDEBUG 
-finline-functions -fno-strict-aliasing -restrict -pthread 
-fvisibility=hidden -MT dt_module.lo -MD -MP -MF .deps/dt_module.Tpo 
-c ../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c -o dt_module.o
../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c(709): warning 
#1224: #warning directive: "No proper C type found for COMPLEX32"

  #   warning "No proper C type found for COMPLEX32"
  ^



I don't know enough about datatypes support to determine if that 
indicates an actual problem or not.


-Paul

Ralph Castain wrote:

Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
give it a whirl.

http://www.open-mpi.org/software/ompi/v1.4/

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.4.3rc1 out

[Paul H. Hargrove]

Testing on Sun C 5.10 on OpenSolaris yield many warnings (below), but 
does build to completion.
I have run a successful "make check", making me doubt that any of the 
atomic.h warnings indicate real problems.


$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc

$ cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03
usage: cc [ options] files.  Use 'cc -flags' for details

$ [path_to]/openmpi-1.4.3rc1/configure CC=cc CXX=CC F77=f77 FC=f90
[...]

$ make
[...]


Many instances of the following:

"../../../../openmpi-1.4.3rc1/opal/include/opal/sys/ia32/atomic.h", line 
170: warning: impossible constraint for "%1" asm operand
"../../../../openmpi-1.4.3rc1/opal/include/opal/sys/ia32/atomic.h", line 
170: warning: parameter in inline asm statement unused: %2
"../../../../openmpi-1.4.3rc1/opal/include/opal/sys/ia32/atomic.h", line 
187: warning: impossible constraint for "%1" asm operand
"../../../../openmpi-1.4.3rc1/opal/include/opal/sys/ia32/atomic.h", line 
187: warning: parameter in inline asm statement unused: %2


Single instances of:

"../../../../openmpi-1.4.3rc1/orte/mca/plm/base/plm_base_orted_cmds.c", 
line 301: warning: statement not reach

ed
"../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c", line 709: 
#warning: "No proper C type found for COMPLEX32"
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 146: Warning 
(Anachronism): Formal argument read_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 147: Warning 
(Anachronism): Formal argument write_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 148: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 173: Warning 
(Anachronism): Formal argument write_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 174: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 198: Warning 
(Anachronism): Formal argument read_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 200: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.4.3rc1/ompi/mpi/cxx/file.cc", line 225: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,vo

[OMPI devel] 1.5rc5 - warnings from Sun C 5.10

[Paul H. Hargrove]

In addition to the atomic.h and Anachronism warnings seen w/ 1.4.3rc1 
(http://www.open-mpi.org/community/lists/devel/2010/08/8322.php), I find 
some "new" warnings in 1.5rc5.


$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc

$ cc -V
cc: Sun C 5.10 SunOS_i386 2009/06/03
usage: cc [ options] files. Use 'cc -flags' for details

$ [path_to]/openmpi-1.5rc5/configure CC=cc CXX=CC F77=f77 FC=f90
[...]

$ make
[...]


DUPLICATE of 1.4.3rc1 warnings:

"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: 
warning: impossible constraint for "%1" asm operand
"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: 
warning: parameter in inline asm statement unused: %2
"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: 
warning: impossible constraint for "%1" asm operand
"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: 
warning: parameter in inline asm statement unused: %2


../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 145: Warning 
(Anachronism): Formal argument read_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 146: Warning 
(Anachronism): Formal argument write_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 147: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 172: Warning 
(Anachronism): Formal argument write_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 173: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 197: Warning 
(Anachronism): Formal argument read_conversion_fn of type extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 199: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 224: Warning 
(Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
int(*)(ompi_datatype_t*,int*,void*) in call to 
MPI_Register_datarep(char*, extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
int(*)(ompi_datatype_t*,int*,void*).

[Though line numbers differ very slightly]


NEW, not seen with 1.4.3rc1, warnings:

Many instances of the following:

"../..

Re: [OMPI devel] A different 1.5rc5 build failure w/ PGI compilers

[Jeff Squyres]

Thanks Paul -- reported in #2544.


On Aug 24, 2010, at 6:07 PM, Paul H. Hargrove wrote:

> I went to try to reproduce the problem Larry Baker reported w/ the PGI 10.3 
> compilers and undefined references in libopen-pal.so when linking 
> opal_wrapper.  Instead I encountered a different error that does not (as best 
> I can tell) correspond to any of the issues Larry has reported recently.  
> Once I disable the error-inducing VT code, I am unable to reproduce Larry's 
> problem with the 10.3, 10.5 or 10.8 PGI compilers.
> 
> My system and the errors:
> 
> $ cat /etc/redhat-release
> Scientific Linux SL release 5.4 (Boron)
> 
> $ uname -a
> Linux cvrsvc01 2.6.18-164.9.1.el5c-perf #1 SMP Wed Jun 9 14:40:25 PDT 2010 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> $ /lib64/libc.so.6GNU C Library stable release version 
> 2.5, by Roland McGrath et al.
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-44).
> Compiled on a Linux 2.6.9 system on 2009-09-02.
> Available extensions:
>   The C stubs add-on version 2.1.2.
>   crypt add-on version 2.1 by Michael Glad and others
>   GNU Libidn by Simon Josefsson
>   GNU libio by Per Bothner
>   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
>   Native POSIX Threads Library by Ulrich Drepper et al
>   BIND-8.2.3-T5B
>   RT using linux kernel aio
> Thread-local storage support included.
> For bug reporting instructions, please see:
> .
> 
> $ pgcc -V  pgcc 10.5-0 64-bit target on x86-64 Linux -tp nehalem-64
> Copyright 1989-2000, The Portland Group, Inc.  All Rights Reserved.
> Copyright 2000-2010, STMicroelectronics, Inc.  All Rights Reserved.
> 
> $ [path_to]/openmpi-1.5rc5/configure CC=pgcc CXX=pgCC F77=pgf77 FC=pgf90
> [...]
> 
> $ make
> [...]
> make[9]: Entering directory 
> `/global/scratch/sd/hargrove/ompi-1.5rc5-pgi-10.5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile'
> CXXotfprofile-otfprofile.o
> "/global/common/carver/usg/pgi/10.5/linux86-64/10.5/include/omp.h", line 41: 
> error:
> expected an identifier
> extern int omp_get_thread_num(void);
>^
> "/global/common/carver/usg/pgi/10.5/linux86-64/10.5/include/omp.h", line 43: 
> error:
> expected an identifier
> extern int omp_get_num_threads(void);
>^
> "../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp",
>  line 572: error:
> this kind of pragma may not be used here
> # pragma omp barrier
>  ^
> "../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp",
>  line 607: error:
> this kind of pragma may not be used here
> # pragma omp barrier
>  ^
> 
> "../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp",
>  line 648: error:
> this kind of pragma may not be used here
> # pragma omp barrier
>  ^
> 
> 5 errors detected in the compilation of 
> "../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp".
> [...]
> 
> It appears that the source file in question ALREADY contains a work-around 
> for this issue:
>> /* Disable OpenMP if the PGI compiler is used to work around the following 
>> errors:
>> 
>> compiler version  compiler error
>> < 9.0-3   PGCC-S--Internal compiler error. calc_dw_tag:no tag
>> (see Technical Problem Report 4337 at 
>> http://www.pgroup.com/support/release_tprs_90.htm)
>> 
>> 10.1 - 10.6   this kind of pragma may not be used here
>>  #pargma omp barrier
>> */
>> #if defined(_OPENMP) && defined(__PGI)
>> #   undef _OPENMP
>> #endif
>> 
>> 
>> #ifdef _OPENMP
>> #   include 
>> #else
>> #   define omp_get_thread_num() 0
>> #   define omp_get_num_threads() 1
>> #endif
> 
> However, it appears that the C++ STL headers (included via Summary.h) are 
> indirectly including omp.h, leading to this failure: the "expected an 
> identifier" due to the two #defines in the work-around, and the "this kind of 
> pragma..." errors due to the original issue resurfacing.
> 
> I have reproduced this problem with PGI versions 10.3, 10.5 and 10.8.
> 
> If I configure with --disable-vt then I (obviously) don't encounter this 
> error.  In that case I am able to complete the build of 1.5rc5 with no 
> errors.  This means an INABILITY to reproduce Larry's undefined references 
> problem.
> 
> -Paul
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research De

Re: [OMPI devel] 1.5rc5 build failure with icc-11.1

[Jeff Squyres]

Also reported in #2544.  Thanks!

On Aug 24, 2010, at 7:14 PM, Paul H. Hargrove wrote:

> Trying to build 1.5rc5 with icc-11.1.046 is failing in otfprofile.cpp - the 
> same file I saw problems with when using the PGI compilers.
> 
> $ cat /etc/SuSE-release
> SUSE Linux Enterprise Server 10 (x86_64)
> VERSION = 10
> PATCHLEVEL = 2
> 
> $  uname -a
> Linux jaguar-ext3 2.6.16.60-0.42.7-smp #1 SMP Tue Nov 3 11:20:42 UTC 2009 
> x86_64 x86_64 x86_64 GNU/Linux
> 
> $ /lib64/libc.so.6
> GNU C Library stable release version 2.4 (20091027), by Roland McGrath et al.
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Configured for x86_64-suse-linux.
> Compiled by GNU CC version 4.1.2 20070115 (SUSE Linux).
> Compiled on a Linux 2.6.16 system on 2009-10-27.
> Available extensions:
>   crypt add-on version 2.1 by Michael Glad and others
>   GNU Libidn by Simon Josefsson
>   GNU libio by Per Bothner
>   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
>   Native POSIX Threads Library by Ulrich Drepper et al
>   BIND-8.2.3-T5B
> Thread-local storage support included.
> For bug reporting instructions, please see:
> .
> 
> $ icc --version
> icc (ICC) 11.1 20090630
> Copyright (C) 1985-2009 Intel Corporation.  All rights reserved.
> 
> $[path_to]/openmpi-1.5rc5/configure CC=icc CXX=icpc F77=ifort FC=ifort
> [...]
> 
> $make
> [...]
> Making all in otfprofile
> make[9]: Entering directory 
> `/lustre/widow1/scratch/hargrove/ompi-1.5rc5-icc-11.1.046/ompi/contrib/vt/vt/extli
> b/otf/tools/otfprofile'
> CXXotfprofile-otfprofile.o
> ../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofile/otfprofile.cpp(25):
>  c
> atastrophic error: could not open source file "omp.h"
> # include 
>  ^
> 
> compilation aborted for 
> ../../../../../../../../../openmpi-1.5rc5/ompi/contrib/vt/vt/extlib/otf/tools/otfprofi
> le/otfprofile.cpp (code 4)
> [...]
> 
> 
> If I configure with --disable-vt then I get a complete build.
> 
> There are numerous instances of ICC's
>   warning #188: enumerated type mixed with another type
> which I personally don't consider to be a serious issue.
> 
> Other than the 188's, there is only one other compiler warning seen:
>> /bin/sh ./libtool  --tag=CC   --mode=compile icc -DHAVE_CONFIG_H -I. 
>> -I../../../openmpi-1.5rc5/opal/libltdl  -DLTDLOPEN=libltdlc 
>> -DLT_CONFIG_H='' -DLTDL -I. -I../../../openmpi-1.5rc5/opal/libltdl 
>> -Ilibltdl -I../../../openmpi-1.5rc5/opal/libltdl/libltdl 
>> -I../../../openmpi-1.5rc5/opal/libltdl/libltdl   -O3 -DNDEBUG   
>> -fvisibility=hidden -MT libltdlc_la-ltdl.lo -MD -MP -MF 
>> .deps/libltdlc_la-ltdl.Tpo -c -o libltdlc_la-ltdl.lo `test -f 'ltdl.c' || 
>> echo '../../../openmpi-1.5rc5/opal/libltdl/'`ltdl.c
>> libtool: compile:  icc -DHAVE_CONFIG_H -I. 
>> -I../../../openmpi-1.5rc5/opal/libltdl -DLTDLOPEN=libltdlc 
>> "-DLT_CONFIG_H=" -DLTDL -I. -I../../../openmpi-1.5rc5/opal/libltdl 
>> -Ilibltdl -I../../../openmpi-1.5rc5/opal/libltdl/libltdl 
>> -I../../../openmpi-1.5rc5/opal/libltdl/libltdl -O3 -DNDEBUG 
>> -fvisibility=hidden -MT libltdlc_la-ltdl.lo -MD -MP -MF 
>> .deps/libltdlc_la-ltdl.Tpo -c ../../../openmpi-1.5rc5/opal/libltdl/ltdl.c -o 
>> libltdlc_la-ltdl.o
>> ../../../openmpi-1.5rc5/opal/libltdl/ltdl.c(1268): warning #279: controlling 
>> expression is constant
>>  archive_name = MALLOC (char, LT_STRLEN (name) + LT_STRLEN (libext) 
>> + 2);
>> ^
> 
> -Paul
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

[OMPI devel] 1.5rc5 warnings from gcc on OpenSolaris

[Paul H. Hargrove]

A build of 1.5rc5 with gcc on OpenSolaris/x86 agrees with my Sun C build 
(http://www.open-mpi.org/community/lists/devel/2010/08/8323.php) about 
type sloppiness in common_sm_mmap.c.


$ uname -a
SunOS osol-x64 5.11 snv_111b i86pc i386 i86pc

$ gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ [path_to]/openmpi-1.5rc5/configure
[...]

$ make
[...]
../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:201: 
warning: assignment from incompatible pointer type
../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:207: 
warning: assignment from incompatible pointer type
../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:280: 
warning: passing arg 1 of `munmap' from incompatible pointer type

[...]

Those are the only warnings generated by this build.

-Paul


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.4.3rc1 out

[George Bosilca]

This indicates that two contiguous C long double types are not identical to a 
Fortran COMPLEX32 type.

Paul, if you still have the config.log and opal_config.h I would like to take a 
look at them.

Thanks,
  george.

On Aug 24, 2010, at 19:38 , Paul H. Hargrove wrote:

> Building w/ icc-11.1.046 on x86-64 works with some warnings.
> 
> In addition to the numerous "188" warnings and the single instance of "279" 
> that I reported seeing for 1.5rc5 
> (http://www.open-mpi.org/community/lists/devel/2010/08/8320.php), there is 
> one additional warning:
>> libtool: compile:  icc -DHAVE_CONFIG_H -I. 
>> -I../../../openmpi-1.4.3rc1/ompi/datatype -I../../opal/include 
>> -I../../orte/include -I../../ompi/include 
>> -I../../opal/mca/paffinity/linux/plpa/src/libplpa 
>> -I../../../openmpi-1.4.3rc1 -I../.. -I../../../openmpi-1.4.3rc1/opal/include 
>> -I../../../openmpi-1.4.3rc1/orte/include 
>> -I../../../openmpi-1.4.3rc1/ompi/include -O3 -DNDEBUG -finline-functions 
>> -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -MT dt_module.lo 
>> -MD -MP -MF .deps/dt_module.Tpo -c 
>> ../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c -o dt_module.o
>> ../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c(709): warning #1224: 
>> #warning directive: "No proper C type found for COMPLEX32"
>>  #   warning "No proper C type found for COMPLEX32"
>>  ^
>> 
> 
> I don't know enough about datatypes support to determine if that indicates an 
> actual problem or not.
> 
> -Paul
> 
> Ralph Castain wrote:
>> Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
>> give it a whirl.
>> 
>> http://www.open-mpi.org/software/ompi/v1.4/
>> 
>> Ralph
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>  
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] 1.5rc5 - warnings from Sun C 5.10

[George Bosilca]

On Aug 24, 2010, at 20:40 , Paul H. Hargrove wrote:

> "../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: 
> warning: impossible constraint for "%1" asm operand

   __asm__ __volatile__(
SMPLOCK "addl %1,%0"
:"=m" (*v)
:"ir" (i), "m" (*v));

The problem seems to come from the "ir". Based on a Sun blog about the gcc 
style asm inlining support 
(http://blogs.sun.com/x86be/entry/gcc_style_asm_inlining_support) it appears 
that i (any size integer immediate constraint) and r (any registers in rax, 
rbx, rcx, rdx, rbp, rsi, rdi, rsp, r8 - r15). As we don't only apply our 
atomics on immediate I think we should drop the "i".

> "../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: 
> warning: parameter in inline asm statement unused: %2

This one is more trickier. Because of the %2 I suspect that the second (*v) on 
the inputs is not matched to the first (*v) on the outputs. While this might be 
significantly bad under some circumstances, in this case I think it can be 
safely ignored.

However I would like to try the following asm code instead with the SUN 
compiler:

   __asm__ __volatile__(
SMPLOCK "addl %1,%0"
:"+m" (*v)
:"r" (i));

  Thanks,
george.


> "../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: 
> warning: impossible constraint for "%1" asm operand
> "../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: 
> warning: parameter in inline asm statement unused: %2
> 
> ../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 145: Warning 
> (Anachronism): Formal argument read_conversion_fn of type extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
> MPI_Register_datarep(char*, extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 146: Warning 
> (Anachronism): Formal argument write_conversion_fn of type extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
> MPI_Register_datarep(char*, extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 147: Warning 
> (Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
> int(*)(ompi_datatype_t*,int*,void*) in call to MPI_Register_datarep(char*, 
> extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern 
> "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(ompi_datatype_t*,int*,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 172: Warning 
> (Anachronism): Formal argument write_conversion_fn of type extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
> MPI_Register_datarep(char*, extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 173: Warning 
> (Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
> int(*)(ompi_datatype_t*,int*,void*) in call to MPI_Register_datarep(char*, 
> extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern 
> "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(ompi_datatype_t*,int*,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 197: Warning 
> (Anachronism): Formal argument read_conversion_fn of type extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to 
> MPI_Register_datarep(char*, extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
> int(*)(ompi_datatype_t*,int*,void*), void*) is being passed 
> int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
> "../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 199: Warning 
> (Anachronism): Formal argument dtype_file_extent_fn of type extern "C" 
> int(*)(ompi_datatype_t*,int*,void*) in call to MPI_Register_datarep(char*, 
> extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern 
> "C" int(*)

[OMPI devel] 1.5rc5 build failure w/ icc-10.1.008 for ia64

[Paul H. Hargrove]

An attempt to compile 1.5rc5 on Linux/IA64 w/ icc-10.0.008 failed:

$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 10 (ia64)
VERSION = 10
PATCHLEVEL = 1

$ cat /etc/sgi-release
SGI ProPack 5SP4 for Linux, Build 504r4-0801072302

$ uname -a
Linux tg-login3.pople.psc.teragrid.org 
2.6.16.60-0.29-default-netboot-lustre-1.6.5.1 #23 SMP Thu Sep 10 
11:35:37 EDT 2009 ia64 ia64 ia64 GNU/Linux


$ /lib/libc.so.6.1
GNU C Library development release version 2.4 (20070503), by Roland 
McGrath et al.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for ia64-suse-linux.
Compiled by GNU CC version 4.1.2 20070115 (prerelease) (SUSE Linux).
Compiled on a Linux 2.6.16 system on 2007-05-03.
Available extensions:
   crypt add-on version 2.1 by Michael Glad and others
   GNU Libidn by Simon Josefsson
   GNU libio by Per Bothner
   NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
   Native POSIX Threads Library by Ulrich Drepper et al
   BIND-8.2.3-T5B
Thread-local storage support included.
For bug reporting instructions, please see:
.

$ icc --version
icc (ICC) 10.1 20070913
Copyright (C) 1985-2007 Intel Corporation.  All rights reserved.

$ [path_to]/openmpi-1.5rc5/configure  CC=icc CXX=icpc F77=ifort FC=ifort
[...]

$ make
[...]
Making all in asm
make[2]: Entering directory 
`/bessemer/hargrove/openmpi-1.5rc5/BLD-icc-10.1.008/opal/asm'

 CC asm.lo
rm -f atomic-asm.S
ln -s "../../../opal/asm/generated/atomic-ia64-linux-nongas.s" atomic-asm.S
 CPPAS  atomic-asm.lo
/tmp/icchjP8pu.s(1) : error A2040: Unexpected token: Unary Diez Operator 
at: Start
/tmp/icchjP8pu.s(2) : error A2040: Unexpected token: Unary Diez Operator 
at: Start
/tmp/icchjP8pu.s(3) : error A2040: Unexpected token: Unary Diez Operator 
at: Start
/tmp/icchjP8pu.s(4) : error A2040: Unexpected token: Unary Diez Operator 
at: Start

.libs/atomic-asm.o - 4 error(s), 0 warning(s)
make[2]: *** [atomic-asm.lo] Error 1


Here is the Assembler section from the configure output, in case it is 
relevant:

*** Assembler
checking dependency style of icc... gcc3
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking for fgrep... /usr/bin/grep -F
checking if need to remove -g from CCASFLAGS... no
checking whether to enable smp locks... yes
checking if .proc/endp is needed... yes
checking directive for setting text section... .text
checking directive for exporting symbols... .globl
checking for objdump... objdump
checking if .note.GNU-stack is needed... no
checking suffix for labels... :
checking prefix for global symbol labels...
checking prefix for lsym labels... .L
checking prefix for function in .type... @
checking if .size is needed... yes
checking if .align directive takes logarithmic value... no
checking if icc supports GCC inline assembly... no
checking if icc supports DEC inline assembly... no
checking if icc supports XLC inline assembly... no
checking if icpc supports GCC inline assembly... no
checking if icpc supports DEC inline assembly... no
checking if icpc supports XLC inline assembly... no
checking for assembly format... default-.text-.globl-:--.L-@-1-0-1-1-0
checking for asssembly architecture... IA64
checking for perl... perl
checking for pre-built assembly file... yes (atomic-ia64-linux-nongas.s)
checking for atomic assembly filename... atomic-ia64-linux-nongas.s


I don't know why atomic-ia64-linux-nongas.s has been selected over 
atomic-ia64-linux.s, but suspect that may be the root of the problem.


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.5rc5 warnings from gcc on OpenSolaris

[George Bosilca]

> ../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:201: 
> warning: assignment from incompatible pointer type
> ../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:207: 
> warning: assignment from incompatible pointer type

This belongs to an assignment to the iov_base member of an "struct iov". We had 
this problem in the past, and we have a solution for it. The pointer stored in 
the iov_base should be casted using (IOVBASE_TYPE*).

> ../../../../../openmpi-1.5rc5/ompi/mca/common/sm/common_sm_mmap.c:280: 
> warning: passing arg 1 of `munmap' from incompatible pointer type

I guess the munmap doesn't take a size_t on this platform ... Too bad, we will 
not be able to allocate more than 2GB of shared memory!

  george.


> [...]
> 
> Those are the only warnings generated by this build.
> 
> -Paul
> 
> 
> -- 
> Paul H. Hargrove  phhargr...@lbl.gov
> Future Technologies Group
> HPC Research Department   Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] 1.4.3rc1 out

[Paul H. Hargrove]

My attempt to build 1.4.3rc1 w/ icc-10.1.008 is failing.
Everything (except the tmpfile name in the error message, of course) is 
identical to what I recently reported for 1.5rc5:

   http://www.open-mpi.org/community/lists/devel/2010/08/8329.php

-Paul

Ralph Castain wrote:

Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
give it a whirl.

http://www.open-mpi.org/software/ompi/v1.4/

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.4.3rc1 out

[George Bosilca]

Paul,

Thanks for the files. It appears that our configure script detected that a 
Fortran REAL*16 bit representation differs from a C long double. This is a 
pretty weird scenario, where a Fortran type cannot be represented in C. As we 
only support C MPI_Op there is no "simple" way we can support this type. As a 
result MPI_REAL16 and MPI_COMPLEX32 types have been disabled, in both C and 
Fortran (and C++ if this still matters), i.e. a user code using these types 
will fails at compile time.

I'm in favor of keeping the warning, at least to inform the user that something 
weird was going on.

  Thanks,
george.

On Aug 24, 2010, at 21:10 , George Bosilca wrote:

> This indicates that two contiguous C long double types are not identical to a 
> Fortran COMPLEX32 type.
> 
> Paul, if you still have the config.log and opal_config.h I would like to take 
> a look at them.
> 
> Thanks,
>  george.
> 
> On Aug 24, 2010, at 19:38 , Paul H. Hargrove wrote:
> 
>> Building w/ icc-11.1.046 on x86-64 works with some warnings.
>> 
>> In addition to the numerous "188" warnings and the single instance of "279" 
>> that I reported seeing for 1.5rc5 
>> (http://www.open-mpi.org/community/lists/devel/2010/08/8320.php), there is 
>> one additional warning:
>>> libtool: compile:  icc -DHAVE_CONFIG_H -I. 
>>> -I../../../openmpi-1.4.3rc1/ompi/datatype -I../../opal/include 
>>> -I../../orte/include -I../../ompi/include 
>>> -I../../opal/mca/paffinity/linux/plpa/src/libplpa 
>>> -I../../../openmpi-1.4.3rc1 -I../.. 
>>> -I../../../openmpi-1.4.3rc1/opal/include 
>>> -I../../../openmpi-1.4.3rc1/orte/include 
>>> -I../../../openmpi-1.4.3rc1/ompi/include -O3 -DNDEBUG -finline-functions 
>>> -fno-strict-aliasing -restrict -pthread -fvisibility=hidden -MT 
>>> dt_module.lo -MD -MP -MF .deps/dt_module.Tpo -c 
>>> ../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c -o dt_module.o
>>> ../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c(709): warning #1224: 
>>> #warning directive: "No proper C type found for COMPLEX32"
>>> #   warning "No proper C type found for COMPLEX32"
>>> ^
>>> 
>> 
>> I don't know enough about datatypes support to determine if that indicates 
>> an actual problem or not.
>> 
>> -Paul
>> 
>> Ralph Castain wrote:
>>> Okay, release candidate 1 for 1.4.3 is now available on the web site. 
>>> Please give it a whirl.
>>> 
>>> http://www.open-mpi.org/software/ompi/v1.4/
>>> 
>>> Ralph
>>> 
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> 
>> 
>> -- 
>> Paul H. Hargrove  phhargr...@lbl.gov
>> Future Technologies Group
>> HPC Research Department   Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] 1.4.3rc1 out

[Paul H. Hargrove]

I suspect that the FORTRAN REAL*16 is a 16-byte floating point type 
while C's "long double" may just be the x86 10-byte type.  I'd not be 
surprised if icc has some option to get 16-byte long double.  I don't 
have time to hunt for such an option, but if somebody know the required 
compiler option, I'll be glad to retest using it.


-Paul

George Bosilca wrote:

Paul,

Thanks for the files. It appears that our configure script detected that a Fortran 
REAL*16 bit representation differs from a C long double. This is a pretty weird scenario, 
where a Fortran type cannot be represented in C. As we only support C MPI_Op there is no 
"simple" way we can support this type. As a result MPI_REAL16 and MPI_COMPLEX32 
types have been disabled, in both C and Fortran (and C++ if this still matters), i.e. a 
user code using these types will fails at compile time.

I'm in favor of keeping the warning, at least to inform the user that something 
weird was going on.

  Thanks,
george.

On Aug 24, 2010, at 21:10 , George Bosilca wrote:

  

This indicates that two contiguous C long double types are not identical to a 
Fortran COMPLEX32 type.

Paul, if you still have the config.log and opal_config.h I would like to take a 
look at them.

Thanks,
 george.

On Aug 24, 2010, at 19:38 , Paul H. Hargrove wrote:



Building w/ icc-11.1.046 on x86-64 works with some warnings.

In addition to the numerous "188" warnings and the single instance of "279" 
that I reported seeing for 1.5rc5 (http://www.open-mpi.org/community/lists/devel/2010/08/8320.php), 
there is one additional warning:
  

libtool: compile:  icc -DHAVE_CONFIG_H -I. 
-I../../../openmpi-1.4.3rc1/ompi/datatype -I../../opal/include 
-I../../orte/include -I../../ompi/include 
-I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../../openmpi-1.4.3rc1 
-I../.. -I../../../openmpi-1.4.3rc1/opal/include 
-I../../../openmpi-1.4.3rc1/orte/include 
-I../../../openmpi-1.4.3rc1/ompi/include -O3 -DNDEBUG -finline-functions 
-fno-strict-aliasing -restrict -pthread -fvisibility=hidden -MT dt_module.lo 
-MD -MP -MF .deps/dt_module.Tpo -c 
../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c -o dt_module.o
../../../openmpi-1.4.3rc1/ompi/datatype/dt_module.c(709): warning #1224: #warning 
directive: "No proper C type found for COMPLEX32"
#   warning "No proper C type found for COMPLEX32"
^



I don't know enough about datatypes support to determine if that indicates an 
actual problem or not.

-Paul

Ralph Castain wrote:
  

Okay, release candidate 1 for 1.4.3 is now available on the web site. Please 
give it a whirl.

http://www.open-mpi.org/software/ompi/v1.4/

Ralph


___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel




___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
  


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] README nit pick (both 1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

I see the following in the Compiler Notes of the Open MPI README (both 
1.5rc5 and 1.4.3rc1)

- Open MPI does not support the Sparc v8 CPU target, which is the
  default on Sun Solaris.  The v8plus (32 bit) or v9 (64 bit)
  targets must be used to build Open MPI on Solaris.  This can be
  done by including a flag in CFLAGS, CXXFLAGS, FFLAGS, and FCFLAGS,
  -xarch=v8plus for the Sun compilers, -mv8plus for GCC.


However, this leads to the following warning on every file compiled with 
the 5.10 (aka Studio 12) compilers:

   cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead

So, the README could use an alternate recommendation for the more recent 
Sun C compilers.


-Paul


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] Success on FreeBSD-8.0 (both 1.5rc5 and 1.4.3rc1)

[Paul H. Hargrove]

By this point you all must either love or hate me, but I still have more 
platforms to test...


This time it is FreeBSD-8.0 on an i386, and I can report that both RCs 
are successful.


However, the build of 1.4.3rc1 produces MANY instances of the following:

In file included from [SOMEFILE:SOMELINE]:
../../opal/include/opal/sys/cache.h:33:1: warning: "CACHE_LINE_SIZE" 
redefined

In file included from /usr/include/sys/param.h:110,
from ../../opal/include/opal_config_bottom.h:311,
from ../opal/include/opal_config.h:1658,
from [SOMEFILE:SOMELINE]:
/usr/include/machine/param.h:89:1: warning: this is the location of the 
previous definition


This warning is NOT seen with 1.5rc5.

-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] 1.5rc5 - warnings from Sun C 5.10

[Paul H. Hargrove]

Following George's advice, I made the following change (NOT yet 
conditional on Sun compiler), and can confirm that it eliminates the 
warnings in atomic.h and "make check" still passes.


-Paul

--- openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h.orig Tue Aug 
24 18:40:55 2010
+++ openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h  Wed Dec 31 
16:00:00 1969

@@ -166,8 +166,8 @@
{
   __asm__ __volatile__(
SMPLOCK "addl %1,%0"
-:"=m" (*v)
-:"ir" (i), "m" (*v));
+:"+m" (*v)
+:"r" (i));
   return (*v);  /* should be an atomic operation */
}

@@ -183,8 +183,8 @@
{
   __asm__ __volatile__(
SMPLOCK "subl %1,%0"
-:"=m" (*v)
-:"ir" (i), "m" (*v));
+:"+m" (*v)
+:"r" (i));
   return (*v);  /* should be an atomic operation */
}








George Bosilca wrote:

On Aug 24, 2010, at 20:40 , Paul H. Hargrove wrote:

  

"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: warning: 
impossible constraint for "%1" asm operand



   __asm__ __volatile__(
SMPLOCK "addl %1,%0"
:"=m" (*v)
:"ir" (i), "m" (*v));

The problem seems to come from the "ir". Based on a Sun blog about the gcc style asm 
inlining support (http://blogs.sun.com/x86be/entry/gcc_style_asm_inlining_support) it appears that 
i (any size integer immediate constraint) and r (any registers in rax, rbx, rcx, rdx, rbp, rsi, 
rdi, rsp, r8 - r15). As we don't only apply our atomics on immediate I think we should drop the 
"i".

  

"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 170: 
warning: parameter in inline asm statement unused: %2



This one is more trickier. Because of the %2 I suspect that the second (*v) on 
the inputs is not matched to the first (*v) on the outputs. While this might be 
significantly bad under some circumstances, in this case I think it can be 
safely ignored.

However I would like to try the following asm code instead with the SUN 
compiler:

   __asm__ __volatile__(
SMPLOCK "addl %1,%0"
:"+m" (*v)
:"r" (i));

  Thanks,
george.


  

"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: warning: 
impossible constraint for "%1" asm operand
"../../../openmpi-1.5rc5/opal/include/opal/sys/ia32/atomic.h", line 187: 
warning: parameter in inline asm statement unused: %2

../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 145: Warning (Anachronism): Formal argument read_conversion_fn 
of type extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to MPI_Register_datarep(char*, 
extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" int(*)(ompi_datatype_t*,int*,void*), void*) 
is being passed int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 146: Warning (Anachronism): Formal argument write_conversion_fn 
of type extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to MPI_Register_datarep(char*, 
extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" int(*)(ompi_datatype_t*,int*,void*), void*) is 
being passed int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 147: Warning (Anachronism): Formal argument 
dtype_file_extent_fn of type extern "C" int(*)(ompi_datatype_t*,int*,void*) in call to MPI_Register_datarep(char*, 
extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" int(*)(ompi_datatype_t*,int*,void*), void*) is 
being passed int(*)(ompi_datatype_t*,int*,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 172: Warning (Anachronism): Formal argument write_conversion_fn 
of type extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*) in call to MPI_Register_datarep(char*, 
extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" int(*)(ompi_datatype_t*,int*,void*), void*) is 
being passed int(*)(void*,ompi_datatype_t*,int,void*,long long,void*).
"../../../../openmpi-1.5rc5/ompi/mpi/cxx/file.cc", line 173: Warning (Anachronism): Formal argument 
dtype_file_extent_fn of type extern "C" int(*)(ompi_datatype_t*,int*,void*) in call to MPI_Register_datarep(char*, 
extern "C" int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" 
int(*)(void*,ompi_datatype_t*,int,void*,long long,void*), extern "C" int(*)(ompi_datat

[OMPI devel] Gcc warnings in datatype test code in 1.5rc5

[Paul H. Hargrove]

The following was seen in a "make check" with 1.5rc5 on FreeBSD-8.0/i386 
w/ gcc-4.2.1, but I don't think that these warnings are platform 
specific.  These warnings do not occur with 1.4.3rc1


I was vaguely recalling that gcc-4.2.1 might be one of the versions that 
generates incorrect "discards qualifiers" warnings.  So, I retried w/ 
gcc-4.4.2, but the results were the same.


-Paul


gmake[3]: Entering directory 
`/home/phargrov/openmpi-1.5rc5/BLD-gcc/test/datatype'

 CC opal_datatype_test.o
In file included from ../../../test/datatype/opal_datatype_test.c:23:
../../../test/datatype/opal_ddt_lib.h:52:33: warning: no newline at end 
of file

../../../test/datatype/opal_datatype_test.c: In function 'main':
../../../test/datatype/opal_datatype_test.c:431: warning: assignment 
discards qualifiers from pointer target type
../../../test/datatype/opal_datatype_test.c:533: warning: passing 
argument 1 of 'test_create_blacs_type1' discards qualifiers from pointer 
target type
../../../test/datatype/opal_datatype_test.c:534: warning: passing 
argument 1 of 'test_create_blacs_type2' discards qualifiers from pointer 
target type

 CC opal_ddt_lib.o
In file included from ../../../test/datatype/opal_ddt_lib.c:23:
../../../test/datatype/opal_ddt_lib.h:52:33: warning: no newline at end 
of file

../../../test/datatype/opal_ddt_lib.c: In function 'test_struct':
../../../test/datatype/opal_ddt_lib.c:154: warning: passing argument 4 
of 'opal_datatype_create_struct' from incompatible pointer type
../../../test/datatype/opal_ddt_lib.c: In function 
'test_struct_char_double':
../../../test/datatype/opal_ddt_lib.c:173: warning: initialization 
discards qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:173: warning: initialization 
discards qualifiers from pointer target type

../../../test/datatype/opal_ddt_lib.c: In function 'mpich_typeub':
../../../test/datatype/opal_ddt_lib.c:642: warning: assignment discards 
qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:662: warning: assignment discards 
qualifiers from pointer target type

../../../test/datatype/opal_ddt_lib.c: In function 'mpich_typeub2':
../../../test/datatype/opal_ddt_lib.c:694: warning: assignment discards 
qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:695: warning: assignment discards 
qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:696: warning: assignment discards 
qualifiers from pointer target type

../../../test/datatype/opal_ddt_lib.c: In function 'mpich_typeub3':
../../../test/datatype/opal_ddt_lib.c:774: warning: assignment discards 
qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:775: warning: assignment discards 
qualifiers from pointer target type
../../../test/datatype/opal_ddt_lib.c:776: warning: assignment discards 
qualifiers from pointer target type


--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] mixed OpenBSD 4.6/i386 results: 1.5rc5 GOOD but 1.4.3rc1 BAD

[Paul H. Hargrove]

I have not sifted through logs for warnings, but can report that 1.5rc5 
builds and passes "gmake check" w/ gcc-3.3.5 on OpenBSD 4.6 on an i386.  
HOWEVER, 1.4.3rc1 fails to build due to errors in ROMIO:


$ uname -a
OpenBSD obsd46-i386.my.domain 4.6 GENERIC#58 i386

$ gcc --version
gcc (GCC) 3.3.5 (propolice)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ [path_to]/openmpi-1.4.3rc1/configure
[...]

$ gmake
[...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. 
-I../../../../../../../../ompi/mca/io/romio/romio/adio/common 
-I../../adio/include -DOMPI_BUILDING=1 
-I../../../../../../../../ompi/mca/io/romio/romio/../../../../.. 
-I../../../../../../../../ompi/mca/io/romio/romio/../../../../../opal/include 
-I../../../../../../../opal/include -I../../../../../../../ompi/include 
-I../../../../../../../../ompi/mca/io/romio/romio/include 
-I../../../../../../../../ompi/mca/io/romio/romio/adio/include -O3 
-DNDEBUG -finline-functions -fno-strict-aliasing -pthread 
-DHAVE_ROMIOCONF_H -DHAVE_ROMIOCONF_H -I../../include -MT ad_fstype.lo 
-MD -MP -MF .deps/ad_fstype.Tpo -c 
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_fstype.c  
-fPIC -DPIC -o .libs/ad_fstype.o
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_fstype.c: 
In function `ADIO_FileSysType_fncall':
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_fstype.c:339: 
error: structure has no member named `f_type'
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_fstype.c:362: 
error: structure has no member named `f_type'
../../../../../../../../ompi/mca/io/romio/romio/adio/common/ad_fstype.c:383: 
error: structure has no member named `f_type'



If I configure with --disable-io-romio then there are no errors in 
"gmake" or in "gmake check".


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] OpenBSD-4.6/i386 warns malloc.h is obsolete for 1.4.3rc1 and 1.5rc5

[Paul H. Hargrove]

Building both of the new RCs on OpenBSD 4.6 for i386 is warning that 
malloc.h is obsolete.  The files/lines producing the warnings are nearly 
the same, but I provide both lists below for completeness.


$ uname -a
OpenBSD obsd46-i386.my.domain 4.6 GENERIC#58 i386

$ gcc --version
gcc (GCC) 3.3.5 (propolice)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


From 1.4rc1 (configured with --disable-io-romio due to 
http://www.open-mpi.org/community/lists/devel/2010/08/8338.php)


In file included from ../../../../ompi/mca/mpool/base/mpool_base_open.c:28:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../ompi/mca/mpool/base/mpool_base_lookup.c:28:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/fake/mpool_fake_component.c:32:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/rdma/mpool_rdma_module.c:36:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/rdma/mpool_rdma_component.c:33:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "



From 1.5rc5:

In file included from ../../../../ompi/mca/mpool/base/mpool_base_open.c:28:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../ompi/mca/mpool/base/mpool_base_lookup.c:28:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../../../../ompi/mca/io/romio/romio/adio/common/malloc.c:29:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/fake/mpool_fake_component.c:30:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/rdma/mpool_rdma_module.c:34:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "

--
In file included from 
../../../../../ompi/mca/mpool/rdma/mpool_rdma_component.c:31:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, 
use "


-Paul

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

[OMPI devel] Success (with warnings) on NetBSD 5.0.2/i386

[Paul H. Hargrove]

Both 1.5rc5 and 1.4.3rc1 build and pass "gmake check" on my NetBSD/i386 
platform.

However, for 1.4.3rc1 (but NOT for 1.5rc5) I see numerous instances of

In file included from [SOMEFILE:SOMELINE]:
../../opal/include/opal/sys/cache.h:33:1: warning: "CACHE_LINE_SIZE" 
redefined

In file included from ../../opal/include/opal_config_bottom.h:311,
from ../opal/include/opal_config.h:1658,
from [SOMEFILE:SOMELINE]:
/usr/include/sys/param.h:172:1: warning: this is the location of the 
previous definition


Which is nearly identical to the warnings I reported for FreeBSD-8.0 in 
http://www.open-mpi.org/community/lists/devel/2010/08/8335.php


-Paul (who /still/ has more platforms to test tonight)

--
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
HPC Research Department   Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900