Re: [OMPI devel] testing if Fortran compiler likes the C++ exception flags
Oops! Sorry about that -- fixed in r26309. On Apr 20, 2012, at 10:01 PM, Eugene Loh wrote: > I think this is related to the "Fortran merge." > > Last night, Oracle MTT tests couldn't build the trunk (r26307) with Intel > compilers. Specifically, configure fails with > >checking to see if Fortran compiler likes the C++ exception flags... no >configure: WARNING: C++ exception flags are different between the C and > Fortran compilers; this >configure script cannot currently handle this scenario. Either disable > C++ exception support or send mail to the Open MPI users list. >configure: error: *** Cannot continue > > Looking in the config.log file, I see this: > >configure:30518: checking to see if Fortran compiler likes the C++ > exception flags >configure:30538: icc -c -O3 -DNDEBUG -Wall -static-intel -m32 > -finline-functions -fno-strict-aliasing -restrict -fexceptions conftest.c >&5 >conftest.c(223): error: identifier "INTEGER" is undefined > INTEGER I > ^ > > Looks like the test is failing because configure is trying to compile Fortran > source code in a *.c file with the C compiler. > ___ > 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] RFC: removing maffinity, paffinity, carto frameworks
WHAT: Remove 3 outdated frameworks: maffinity, paffinity, carto WHY: Their functionality is wholly replaced by hwloc. Removing these frameworks has actually been a to-do item since we made hwloc a 1st-class citizen in OMPI. WHERE: rm -rf opal/mca/[maffinity, paffinity, carto], and update various places around the tree that use these frameworks to use hwloc instead TIMEOUT: Tuesday teleconference, 1 May 2012 - More details: The maffinity (memory affinity), paffinity (processor affinity), and carto (cartography) frameworks are now outdated. All of their functionality (and much more) can be effected with hwloc. Indeed, all three frameworks had significant limitations in one way or another -- hwloc is a much more general solution to all three (no more needing to specify carto files -- woo hoo!). Note that this officially opens the door for more hwloc usage within Open MPI. The opal_hwloc_topology global variable will filled in after orte_init() completes (which is pretty early in ompi_mpi_init()). There's also a bunch of hwloc helper functions in opal/mca/hwloc/base/base.h (e.g., use opal_hwloc_base_get_level_and_index() to get a simple enum back indicating the locality of where this process has been bound). === ==>> Let the hwlocness begin!! <<== === Ralph and I have a bitbucket where we have removed all 3 of these frameworks: https://bitbucket.org/jsquyres/ompi-remove-paff-maff *** Notable items that came out of the implementation: - The sm BTL used to (potentially) make multiple mpools if a carto file was supplied. It now only makes 1 mpool. However, based on UTK's Euro MPI 2010 paper, the optimization of creating multiple mpools based on NUMA information may be re-added in the future. - Ditto for the smcuda BTL. - Nathan tells me that he's going to do the same for the vader BTL; I have therefore not done so. - The openib BTL will shortly have its use of carto (to find nearby IBV devices) re-implemented using hwloc distances. - Ditto for wv. - The "affinity" mpiext was effectively completely re-implemented. It now shows hyperthread information, too. - New ORTE-level global variables: - orte_proc_is_bound: a boolean that is set after orte_init that indicates whether this process is bound or not (regardless of who bound the process). - orte_proc_applied_binding: if OMPI bound this process, this hwloc_cpuset_t will contain the *physical* PUs where it was bound *** IMPORTANT hwloc CONSIDERATIONS TO REMEMBER (because getting this wrong screwed us up more than once): - The cpusets hanging off hwloc objects represent PHYSICAL indices - The objects in the hwloc tree are in LOGICAL order ==>> BE SURE TO USE obj->physical_index OR obj->logical_index AS APPROPRIATE! -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to:http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] configure check for Fortran and threads
Another probably-Fortran-merge problem. Three issues in this e-mail.
Introduction: The last two nights, Oracle MTT tests have been unable to
build the trunk (r26307) with Oracle Studio compilers. This has been
uncovered since the fix of r26302, allowing us to get further in the
build process. We configure with
--with-openib
--enable-openib-connectx-xrc
--without-udapl
--disable-openib-ibcm
--enable-btl-openib-failover
[...]
and fail in compilation with
"btl_openib_failover.c", line 237: undefined struct/union member:
port_error_failover
The member is defined in btl_openib.h, but it's inside an "#if
OPAL_HAVE_THREADS" and we're not getting threads.
#1) Isn't there supposed to be some diplomatic message about trying to
use openib without threads?
Anyhow, why aren't we getting threads? Well, configure complains:
checking if Fortran compiler and POSIX threads work as is... no
checking if Fortran compiler and POSIX threads work with -Kthread... no
checking if Fortran compiler and POSIX threads work with -kthread... no
checking if Fortran compiler and POSIX threads work with -pthread... no
checking if Fortran compiler and POSIX threads work with -pthreads... no
checking if Fortran compiler and POSIX threads work with -mt... no
checking if Fortran compiler and POSIX threads work with -mthreads... no
checking if Fortran compiler and POSIX threads work with -lpthreads... no
checking if Fortran compiler and POSIX threads work with -llthread... no
checking if Fortran compiler and POSIX threads work with -lpthread... no
Woke up on the wrong side of bed, did we? Checking config.log:
configure:58332: checking if Fortran compiler and POSIX threads work as is
configure:58417: cc -DNDEBUG -m32 -xO5 -I. -c conftest.c
"conftest.c", line 21: void function cannot return value
"conftest.c", line 24: void function cannot return value
"conftest.c", line 27: void function cannot return value
"conftest.c", line 30: void function cannot return value
[...]
void pthreadtest(void)
{ return pthreadtest_f(); }
[...]
void pthreadtest_(void)
{ return pthreadtest_f(); }
[...etc...]
#2) Okay, yes, we shouldn't be trying to return values from void functions.
Same for the other checks (-pthread, -pthreads, -mt, etc.). But,
something else strikes me as funny about those other checks. Here is
more from config.log:
configure:58698: checking if Fortran compiler and POSIX threads work
with -Kthread
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:58698: checking if Fortran compiler and POSIX threads work
with -kthread
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:58698: checking if Fortran compiler and POSIX threads work
with -pthread
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:58698: checking if Fortran compiler and POSIX threads work
with -pthreads
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:58698: checking if Fortran compiler and POSIX threads work
with -mt
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:58698: checking if Fortran compiler and POSIX threads work
with -mthreads
configure:58768: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:59320: checking if Fortran compiler and POSIX threads work
with -lpthreads
configure:59390: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:59320: checking if Fortran compiler and POSIX threads work
with -llthread
configure:59390: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
configure:59320: checking if Fortran compiler and POSIX threads work
with -lpthread
configure:59390: cc -DNDEBUG -m32 -xO5 -mt -I. -c conftest.c
[...]
The purged text complains about void functions returning values, but we
already talked about that. What interests me now is this:
#3) While configure claims to be trying so many flags (-pthread, -mt,
etc.) it appears always to be checking only -mt.
