Re: [OMPI devel] 1.5rc5 has been posted

2010-08-19 Thread Larry Baker
The PGI compiler unnecessarily complains (issues a warning) when 0 (which it should be automatically converting to the null pointer constant) is an operand in a conditional expression. For example, there are two instances (lines 444 and 459) in opal/mca/memory/ ptmalloc2/hooks.c: 444 and

Re: [OMPI devel] 1.5rc5 has been posted

2010-08-19 Thread Larry Baker
The PGI C compiler complains (issues a warning) for the #pragma ident in opal/runtime/opal_init.c: PGC-W-0281-Pragma ignored - string expected after #pragma ident (../ opal/util/sys_limits.h: 58) This is because the PCI C compiler does not (whereas, curiously, the PGI C++ compiler does) s

Re: [OMPI devel] 1.5rc5 has been posted

2010-08-19 Thread Larry Baker
Both the Intel and PGI compilers complain (issue a warning) about the arguments to the LT_STRLEN() macro in opal/libltdl/ltdl.c: ltdl.c(1268): warning #279: controlling expression is constant archive_name = MALLOC (char, LT_STRLEN (name) + LT_STRLEN (libext) + 2);

Re: [OMPI devel] 1.5rc5 has been posted

2010-08-19 Thread Larry Baker
Both PGI C and C++ have issues with the inline assembly in OpenMPI. configure includes the code below to disable the inline assembly test for PGI C. The same code needs to be inserted for the C++ inline assembly test as well. { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $CC su

Re: [OMPI devel] 1.5rc5 has been posted

2010-08-19 Thread Larry Baker
The PGI compiler version number parsing in the libtool.m4 files is incorrect. It should be like the parser in configure, i.e., there should be a period between "]]" and "*" [baker@hydra openmpi-1.5rc5]$ grep '1-5' configure *pgCC\ [1-5].* | *pgcpp\ [1-5].*) [baker@hydra openmpi-

Re: [OMPI devel] [OMPI svn] svn:open-mpi r23628

2010-08-19 Thread Ralph Castain
Yes - the selection logic now only picks ONE module to run. On Thu, Aug 19, 2010 at 12:01 PM, Wesley Bland wrote: > So just to clarify, this means that we don't need to worry about having > more than one errmgr module handling a single failure and therefore don't > have to set the stack_state (w

Re: [OMPI devel] [OMPI svn] svn:open-mpi r23628

2010-08-19 Thread Wesley Bland
So just to clarify, this means that we don't need to worry about having more than one errmgr module handling a single failure and therefore don't have to set the stack_state (which is now gone anyway). Am I reading this correctly? Thanks, Wesley On Thu, Aug 19, 2010 at 9:09 AM, wrote: > Author