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);
^
PGC-W-0089-Array name used in logical expression (ltdl.c: 1268)
The Intel compiler seems to be complaining about the const'ness of the
static const libext array name:
savaii:libltdl baker$ icc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdlc "-
DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./
libltdl -g -O3 -MT libltdlc_la-ltdl.lo -MD -MP -MF .deps/libltdlc_la-
ltdl.Tpo -c ltdl_cpp.c -fno-common -DPIC -o .libs/libltdlc_la-
ltdl.oltdl.c(1268): warning #279: controlling expression is constant
archive_name = (char*) lt__malloc(((((name) && (name)[0]) ?
strlen (name) : 0) + (((libext) && (libext)[0]) ? strlen (libext) : 0)
+ 2) * sizeof(char));
^
The PGI compiler seems to not like an array name (which it should be
automatically converting to a pointer) as the scalar first operand to
a conditional expression.
Both complaints disappear when the definition of the LT_STRLEN() macro
in opal/libltdl/ltdl.h is changed from
#define LT_STRLEN(s) (((s) && (s)[0]) ? strlen (s) : 0)
to the functionally equivalent
#define LT_STRLEN(s) ((s!=NULL) ? strlen (s) : 0)
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
