Re: [OMPI devel] 1.4.4rc2 is up
(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 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. There is a missing period in the pattern, so that only
> text like 1.x through 5.x matches.
>
> Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
>
>> [root@hydra openmpi-1.4.3]# diff -u config/libtool.m4{.original,}
>> --- config/libtool.m4.original 2010-10-05 15:45:44.0 -0700
>> +++ config/libtool.m42011-05-17 15:32:31.0 -0700
>> @@ -5896,7 +5896,7 @@
>>pgCC* | pgcpp*)
>> # Portland Group C++ compiler
>> case `$CC -V` in
>> -*pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
>> +*pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
>>_LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
>> rm -rf $tpldir~
>> $CC --prelink_objects --instantiation_dir $tpldir $objs
>> $libobjs $compile_deplibs~
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
>
>> 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/
>>
>>
>> ___
>> 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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] 1.4.4rc2 is up
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 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 assembly for C++.
>
> Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
>
>> [root@hydra openmpi-1.4.3]# diff -u configure{.original,}
>> --- configure.original 2010-10-05 15:48:18.0 -0700
>> +++ configure2011-05-17 18:35:04.0 -0700
>> @@ -34690,6 +34690,11 @@
>> { $as_echo "$as_me:$LINENO: checking if $CXX supports GCC inline
>> assembly" >&5
>> $as_echo_n "checking if $CXX supports GCC inline assembly... " >&6; }
>>
>> +if test "$ompi_cv_cxx_compiler_vendor" = "portland group" ; then
>> +# PGI seems to have some issues with our inline assembly.
>> +# Disable for now.
>> +asm_result="no (Portland Group)"
>> +else
>> case $host in
>> *-aix*)
>> # the AIX compilers and linkers really don't do gcc
>> @@ -34813,6 +34818,7 @@
>> rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
>>conftest$ac_exeext conftest.$ac_ext
>> fi
>> +fi
>>
>> { $as_echo "$as_me:$LINENO: result: $asm_result" >&5
>> $as_echo "$asm_result" >&6; }
>
> Larry Baker
> US Geological Survey
> 650-329-5608
> ba...@usgs.gov
>
> On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
>
>> 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/
>>
>>
>> ___
>> 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
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] 1.4.4rc2 is up
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/community/lists/users/2009/11/11277.php
.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 18 May 2011, at 5:50 AM, Jeff Squyres wrote:
(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 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. There is a
missing period in the pattern, so that only text like 1.x through
5.x matches.
Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):
[root@hydra openmpi-1.4.3]# diff -u config/libtool.m4{.original,}
--- config/libtool.m4.original 2010-10-05 15:45:44.0 -0700
+++ config/libtool.m4 2011-05-17 15:32:31.0 -0700
@@ -5896,7 +5896,7 @@
pgCC* | pgcpp*)
# Portland Group C++ compiler
case `$CC -V` in
- *pgCC\ [[1-5]]* | *pgcpp\ [[1-5]]*)
+ *pgCC\ [[1-5]].* | *pgcpp\ [[1-5]].*)
_LT_TAGVAR(prelink_cmds, $1)='tpldir=Template.dir~
rm -rf $tpldir~
$CC --prelink_objects --instantiation_dir $tpldir $objs $libobjs
$compile_deplibs~
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov
On 5 May 2011, at 7:15 AM, Jeff Squyres wrote:
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/
___
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
--
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
Re: [OMPI devel] 1.4.4rc2 is up
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 Reserved. Including the initial blank line. Here is the "important" line for a range of versions I can currently access: pgCC 7.2-5 64-bit target on x86-64 Linux -tp gh-64 pgCC 8.0-6 64-bit target on x86-64 Linux -tp gh-64 pgCC 9.0-3 64-bit target on x86-64 Linux -tp nehalem-64 pgCC 10.8-0 64-bit target on x86-64 Linux -tp nehalem-64 pgCC 11.1-0 64-bit target on x86-64 Linux -tp nehalem I am afraid my system w/ 5.x and 6.x versions was retired last month (not joking). However, I found the following output for the C (not C++) compiler in my bug database: pgcc 6.0-8 32-bit target on x86-64 Linux And for their MacOSX port, there is a wrinkle. As anybody who as dealt w/ mpicc vs mpiCC knows, Apple's filesystem is case PRESERVING but case-insensitive. So, there PGI's C++ compiler is "pgcpp" and the -V output (also from my bug database) looks like: pgcpp 7.1-5 64-bit target on Apple OS/X -Paul On 5/18/2011 5:50 AM, Jeff Squyres wrote: (addinglibtool-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)+\. ? -- 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.4rc2 is up
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 target on x86-64 Linux -tp gh-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2009, STMicroelectronics, Inc. All Rights Reserved. $ pgCC -V pgCC 10.3-0 64-bit target on x86-64 Linux -tp istanbul-64 Copyright 1989-2000, The Portland Group, Inc. All Rights Reserved. Copyright 2000-2010, STMicroelectronics, Inc. All Rights Reserved. -- Samuel Gutierrez Los Alamos National Laboratory On May 18, 2011, at 12:34 PM, Paul H. Hargrove wrote: > 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 Reserved. > > Including the initial blank line. > > Here is the "important" line for a range of versions I can currently access: > > pgCC 7.2-5 64-bit target on x86-64 Linux -tp gh-64 > pgCC 8.0-6 64-bit target on x86-64 Linux -tp gh-64 > pgCC 9.0-3 64-bit target on x86-64 Linux -tp nehalem-64 > pgCC 10.8-0 64-bit target on x86-64 Linux -tp nehalem-64 > pgCC 11.1-0 64-bit target on x86-64 Linux -tp nehalem > > I am afraid my system w/ 5.x and 6.x versions was retired last month (not > joking). > However, I found the following output for the C (not C++) compiler in my bug > database: > > pgcc 6.0-8 32-bit target on x86-64 Linux > > And for their MacOSX port, there is a wrinkle. As anybody who as dealt w/ > mpicc vs mpiCC knows, Apple's filesystem is case PRESERVING but > case-insensitive. So, there PGI's C++ compiler is "pgcpp" and the -V output > (also from my bug database) looks like: > > pgcpp 7.1-5 64-bit target on Apple OS/X > > > -Paul > > > On 5/18/2011 5:50 AM, Jeff Squyres wrote: >> (addinglibtool-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)+\. ? > > -- > 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.4rc2 is up
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 the specific problem that caused you to add this patch?These warning messages are from PGI C++ 11.4 for the assembly language macros in OpenMPI 1.4.3 opal/include/opal/sys/amd64/atomic.h:libtool: compile: pgcpp -m64 -DHAVE_CONFIG_H -I. -I../../../opal/include -I../../../orte/include -I../../../ompi/include -I../../../opal/mca/paffinity/linux/plpa/src/libplpa -DOMPI_BUILDING_CXX_BINDINGS_LIBRARY=1 -DOMPI_SKIP_MPICXX=1 -I../../.. -D_REENTRANT -DNDEBUG -g -O3 -DNO_PGI_OFFSET -c mpicxx.cc -fpic -DPIC -o .libs/mpicxx.o"../../../opal/include/opal/sys/amd64/atomic.h", line 91: warning: "cc" clobber ignored : "memory", "cc"); ^"../../../opal/include/opal/sys/amd64/atomic.h", line 83: warning: parameter "oldval" was set but never used int32_t oldval, int32_t newval) ^"../../../opal/include/opal/sys/amd64/atomic.h", line 112: warning: "cc" clobber ignored : "memory", "cc" ^"../../../opal/include/opal/sys/amd64/atomic.h", line 104: warning: parameter "oldval" was set but never used int64_t oldval, int64_t newval) ^configure defines OMPI_CXX_GCC_INLINE_ASSEMBLY as 1 in opal/include/opal_config.h (unlike OMPI_C_GCC_INLINE_ASSEMBLY, which is defined as 0), which causes the assembly language macros to be used:# find . -name \*.h -exec grep \#define.\*OMPI_.\*_INLINE_ASSEMBLY {} ';' -print#define OMPI_CXX_DEC_INLINE_ASSEMBLY 0#define OMPI_CXX_GCC_INLINE_ASSEMBLY 1#define OMPI_CXX_XLC_INLINE_ASSEMBLY 0#define OMPI_C_DEC_INLINE_ASSEMBLY 0#define OMPI_C_GCC_INLINE_ASSEMBLY 0#define OMPI_C_XLC_INLINE_ASSEMBLY 0./opal/include/opal_config.h Larry BakerUS Geological Survey650-329-5608ba...@usgs.gov On 18 May 2011, at 6:17 AM, Jeff Squyres wrote: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 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 assembly for C++.Here's the diff -u from OpenMPI 1.4.3 (same code, same bug):[root@hydra openmpi-1.4.3]# diff -u configure{.original,}--- configure.original 2010-10-05 15:48:18.0 -0700+++ configure 2011-05-17 18:35:04.0 -0700@@ -34690,6 +34690,11 @@ { $as_echo "$as_me:$LINENO: checking if $CXX supports GCC inline assembly" >&5 $as_echo_n "checking if $CXX supports GCC inline assembly... " >&6; }+ if test "$ompi_cv_cxx_compiler_vendor" = "portland group" ; then+ # PGI seems to have some issues with our inline assembly.+ # Disable for now.+ asm_result="no (Portland Group)"+ else case $host in *-aix*) # the AIX compilers and linkers really don't do gcc@@ -34813,6 +34818,7 @@ rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \ conftest$ac_exeext conftest.$ac_ext fi+ fi { $as_echo "$as_me:$LINENO: result: $asm_result" >&5 $as_echo "$asm_result" >&6; }Larry BakerUS Geological Survey650-329-5608ba...@usgs.govOn 5 May 2011, at 7:15 AM, Jeff Squyres wrote:Fixed the ROMIO attribute problem properly this time -- it's in the usual place: http://www.open-mpi.org/software/ompi/v1.4/-- Jeff Squyresjsquy...@cisco.comFor corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/___devel mailing listde...@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/devel___devel mailing listde...@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/devel-- Jeff Squyresjsquy...@cisco.comFor corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/___devel mailing listde...@open-mpi.orghttp://www.open-mpi.org/mailman/listinfo.cgi/devel
patch-openmpi-1.4.2.sh
Description: Binary data
[OMPI devel] SSE instructions?
The PGI compilers have a -fast and a -fastsse option. Does OpenMPI make effective/safe use of SSE instructions (block moves maybe?)? On their web site, PGI uses -fast in their examples for OpenMPI rather than -fastsse. I don't know why. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov
