I see in ompi/mca/btl/openib/btl_openib/connect/
btl_openib_connect_oob.c and .../btl_openib_connect_xoob.c what looks
like assignments of the form
path_mtu = MIN( device_mtu, remote_mtu );
In ompi/mca/btl/openib/btl_openib/connect/
btl_openib_connect_oob.c(289) it looks correct:
Jeff,
I get the following warnings from "make" using the Intel 2011.3.174
compilers on OpenMPI 1.4.3:
btl_openib_endpoint.c(319): warning #188: enumerated type mixed with
another type
btl_openib_async.c(411): warning #188: enumerated type mixed with
another type
btl_openib_async.c(454
Jeff,
I get the following warning from "make" using the Intel 2011.3.174
compilers on OpenMPI 1.4.3:
libtool: compile: icc -DHAVE_CONFIG_H -I. -I../../opal/include -
I../../orte/include -I../../ompi/include -I../../opal/mca/paffinity/
linux/plpa/src/libplpa -I../.. -DNDEBUG -g -O3 -finline
Jeff,
I get warnings from all my compilers running "make check" when
compiling test/class/ompi_rb_tree.c. For example, using gcc/g++/
gfortran:
ompi_rb_tree.c: In function 'test2':
ompi_rb_tree.c:347: warning: cast to pointer from integer of
different size
ompi_rb_tree.c:365: warning: ca
Jeff,
I ran into some kind of link error, I think, with PGI 10.3 and OpenMPI
1.4.2 last year. I am building a new cluster and we have PGI 11.4
now. I am consulting my notes and patches from 1.4.2 to inspect 1.4.3
to see if the problems I had have been fixed. I found the .m4 files I
pat
With all the outputs from Paul and Sam, I think we'll be good.
...hmmm. Wait. I see that our 1.4.x configure *is* patched to have the extra
".". Here's the lines from configure in 1.4.3 and 1.4.4rc2:
# Portland Group C++ compiler
This is a function of using two different subsystems that both put in their own
--with-valgrind options in different .m4 scripts. It's solved in a different
way on the trunk / v1.5. So I think we'll just have to live with it for
v1.4.x. :-\
Many thanks for all these close inspections!
On M
The help text for --with-valgrind in configure appears twice (fixed in
1.5.3)
--with-libnuma-libdir=DIR
Directory where the libnuma software is
installed
--with-valgrind(=DIR) Directory where the valgrind software is
installed
--with-memory-manager=TYPE
Consider adding the improved description for --with-tm from 1.5.3
--with-tm(=DIR) Build TM (Torque, PBSPro, and compatible)
support,
optionally adding DIR/include, DIR/lib, and
DIR/lib64 to the search path for headers and
Jeff,Hmm. This sounds right, but I'm a little curious as to why this never came up before.I reported this, as well as several others, in August 2010, "Fixes to OpenMPI-1.4.2 for PGI compilers". (Attached are my patches for OpenMPI 1.4.2.) At that time I was using the PGI 10.x compilers.What was
Here is the 'pgCC -V' output from versions that I have access to.
$ pgCC -V
pgCC 7.1-6 64-bit target on x86-64 Linux -tp gh-64
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2007, STMicroelectronics, Inc. All Rights Reserved.
$ pgCC -V
pgCC 9.0-3 64-bit ta
Below is a sampling of "pgCC -V" outputs in response to Jeff's question.
The complete output looks like:
$ pgCC -V
pgCC 11.1-0 64-bit target on x86-64 Linux -tp nehalem
Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved.
Copyright 2000-2011, STMicroelectronics, Inc. All Rights R
Jeff,
Is this guaranteed to work for all versions of the PGI compiler?
I.e., does "pgCC -V" always return something in the form of (digit)+
\. ?
I don't know, but I think so. See your Nov 2009 discussion of this
bug and Ralf Wildenhues' libtool.m4 patches at http://www.open-mpi.org/commu
Hmm. This sounds right, but I'm a little curious as to why this never came up
before. What was the specific problem that caused you to add this patch?
On May 17, 2011, at 9:41 PM, Larry Baker wrote:
> This bug applies to OpenMPI 1.4.x and 1.5.x.
>
> Inline assembly does not work for PGI comp
(adding libtool-patc...@gnu.org)
Is this guaranteed to work for all versions of the PGI compiler? I.e., does
"pgCC -V" always return something in the form of (digit)+\. ?
On May 17, 2011, at 8:52 PM, Larry Baker wrote:
> This bug applies to OpenMPI 1.4.x and 1.5.x.
>
> The libtool.m4 in conf
This bug applies to OpenMPI 1.4.x and 1.5.x.
Inline assembly does not work for PGI compilers. configure disables
inline assembly for PGI C, but neglects to do the same for PGI C++.
The code that disables inline assembly for PGI C needs to be copied to
the section that handles inline assem
This bug applies to OpenMPI 1.4.x and 1.5.x.
The libtool.m4 in config and opal/libltdl/m4 do not properly determine
the version of the PGI compiler, which then set the wrong compile/link
options. They interpret V11.4 (version no. begins with a 1), for
example, as being a V1 to V5 compiler.
Fixed the ROMIO attribute problem properly this time -- it's in the usual place:
http://www.open-mpi.org/software/ompi/v1.4/
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
18 matches
Mail list logo
