March 2015 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Bland, Wesley B. 10 Mar '15

10 Mar '15

I’ll take a look. That’s my nasty code. On 3/9/15, 8:24 PM, ""Antonio J. Peña"" <apenya(a)mcs.anl.gov> wrote: > >Thanks Jeff. This will be ticket #2245 > > http://trac.mpich.org/projects/mpich/ticket/2245 > > >On 03/09/2015 08:02 PM, Jeff Hammond wrote: >> See below, but the propriety of this cast can be verified in source >> without a compiler :-) >> >> Jeff >> >> ## Local Branches: >> >> * master >> >> ## Most Recent Commit: >> >> commit 957ceec598103d8d643c9345512ae8ad4e88e993 >> Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> >> >> testsuite: remove leading spaces in testlist files >> >> jrhammon-mac01:build jrhammon$ head config.log >> This file contains any messages produced by compilers while >> running configure, to aid debugging if configure makes a mistake. >> >> It was created by MPICH configure 3.2b1, which was >> generated by GNU Autoconf 2.69. Invocation command line was >> >> $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran >> --enable-threads=runtime --enable-g=dbg --with-pm=hydra >> --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath >> --enable-static --enable-shared >> >> jrhammon-mac01:build jrhammon$ icc --version >> icc (ICC) 15.0.1 20141022 >> Copyright (C) 1985-2014 Intel Corporation. All rights reserved. >> >> >> >> On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: >>> Hi Jeff, >>> >>> Please also report compiler, compiler version, and MPICH version. >>> >>> Best, >>> Toni >>> >>> >>> >>> On 03/09/2015 07:53 PM, Jeff Hammond wrote: >>>> I know some of you like warning-clean builds... >>>> >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >>>> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >>>> converts between pointers to integer types with different sign >>>> [-Wpointer-sign] >>>> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >>>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>>> with result type 'int *' converts between pointers to integer >>>> types with different sign [-Wpointer-sign] >>>> return bitarray; >>>> ^~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >>>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>>> with result type 'int *' converts between pointers to integer >>>> types with different sign [-Wpointer-sign] >>>> return bitarray; >>>> ^~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >>>> assigning to 'uint32_t *' (aka 'unsigned int *') from >>>> 'int *' converts between pointers to integer types with >>>> different sign [-Wpointer-sign] >>>> bitarray = group_to_bitarray(local_fail, comm_ptr); >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 4 warnings generated. >>>> >>>> Best, >>>> >>>> Jeff >>>> >>> >>> -- >>> Antonio J. Peña >>> Postdoctoral Appointee >>> Mathematics and Computer Science Division >>> Argonne National Laboratory >>> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >>> Argonne, IL 60439-4847 >>> apenya(a)mcs.anl.gov >>> www.mcs.anl.gov/~apenya >>> >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> > > >-- >Antonio J. Peña >Postdoctoral Appointee >Mathematics and Computer Science Division >Argonne National Laboratory >9700 South Cass Avenue, Bldg. 240, Of. 3148 >Argonne, IL 60439-4847 >apenya(a)mcs.anl.gov >www.mcs.anl.gov/~apenya > >_______________________________________________ >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by "Antonio J. Peña" 09 Mar '15

09 Mar '15

Thanks Jeff. This will be ticket #2245 http://trac.mpich.org/projects/mpich/ticket/2245 On 03/09/2015 08:02 PM, Jeff Hammond wrote: > See below, but the propriety of this cast can be verified in source > without a compiler :-) > > Jeff > > ## Local Branches: > > * master > > ## Most Recent Commit: > > commit 957ceec598103d8d643c9345512ae8ad4e88e993 > Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> > > testsuite: remove leading spaces in testlist files > > jrhammon-mac01:build jrhammon$ head config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by MPICH configure 3.2b1, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran > --enable-threads=runtime --enable-g=dbg --with-pm=hydra > --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath > --enable-static --enable-shared > > jrhammon-mac01:build jrhammon$ icc --version > icc (ICC) 15.0.1 20141022 > Copyright (C) 1985-2014 Intel Corporation. All rights reserved. > > > > On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: >> Hi Jeff, >> >> Please also report compiler, compiler version, and MPICH version. >> >> Best, >> Toni >> >> >> >> On 03/09/2015 07:53 PM, Jeff Hammond wrote: >>> I know some of you like warning-clean builds... >>> >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >>> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >>> converts between pointers to integer types with different sign >>> [-Wpointer-sign] >>> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>> with result type 'int *' converts between pointers to integer >>> types with different sign [-Wpointer-sign] >>> return bitarray; >>> ^~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>> with result type 'int *' converts between pointers to integer >>> types with different sign [-Wpointer-sign] >>> return bitarray; >>> ^~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >>> assigning to 'uint32_t *' (aka 'unsigned int *') from >>> 'int *' converts between pointers to integer types with >>> different sign [-Wpointer-sign] >>> bitarray = group_to_bitarray(local_fail, comm_ptr); >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 4 warnings generated. >>> >>> Best, >>> >>> Jeff >>> >> >> -- >> Antonio J. Peña >> Postdoctoral Appointee >> Mathematics and Computer Science Division >> Argonne National Laboratory >> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >> Argonne, IL 60439-4847 >> apenya(a)mcs.anl.gov >> www.mcs.anl.gov/~apenya >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Jeff Hammond 09 Mar '15

09 Mar '15

See below, but the propriety of this cast can be verified in source without a compiler :-) Jeff ## Local Branches: * master ## Most Recent Commit: commit 957ceec598103d8d643c9345512ae8ad4e88e993 Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> testsuite: remove leading spaces in testlist files jrhammon-mac01:build jrhammon$ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by MPICH configure 3.2b1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran --enable-threads=runtime --enable-g=dbg --with-pm=hydra --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath --enable-static --enable-shared jrhammon-mac01:build jrhammon$ icc --version icc (ICC) 15.0.1 20141022 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: > > Hi Jeff, > > Please also report compiler, compiler version, and MPICH version. > > Best, > Toni > > > > On 03/09/2015 07:53 PM, Jeff Hammond wrote: >> >> I know some of you like warning-clean builds... >> >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >> converts between pointers to integer types with different sign >> [-Wpointer-sign] >> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >> returning 'uint32_t *' (aka 'unsigned int *') from a function >> with result type 'int *' converts between pointers to integer >> types with different sign [-Wpointer-sign] >> return bitarray; >> ^~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >> returning 'uint32_t *' (aka 'unsigned int *') from a function >> with result type 'int *' converts between pointers to integer >> types with different sign [-Wpointer-sign] >> return bitarray; >> ^~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >> assigning to 'uint32_t *' (aka 'unsigned int *') from >> 'int *' converts between pointers to integer types with >> different sign [-Wpointer-sign] >> bitarray = group_to_bitarray(local_fail, comm_ptr); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 4 warnings generated. >> >> Best, >> >> Jeff >> > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847 > apenya(a)mcs.anl.gov > www.mcs.anl.gov/~apenya > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by "Antonio J. Peña" 09 Mar '15

09 Mar '15

Hi Jeff, Please also report compiler, compiler version, and MPICH version. Best, Toni On 03/09/2015 07:53 PM, Jeff Hammond wrote: > I know some of you like warning-clean builds... > > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: > assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' > converts between pointers to integer types with different sign > [-Wpointer-sign] > bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: > returning 'uint32_t *' (aka 'unsigned int *') from a function > with result type 'int *' converts between pointers to integer > types with different sign [-Wpointer-sign] > return bitarray; > ^~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: > returning 'uint32_t *' (aka 'unsigned int *') from a function > with result type 'int *' converts between pointers to integer > types with different sign [-Wpointer-sign] > return bitarray; > ^~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: > assigning to 'uint32_t *' (aka 'unsigned int *') from > 'int *' converts between pointers to integer types with > different sign [-Wpointer-sign] > bitarray = group_to_bitarray(local_fail, comm_ptr); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4 warnings generated. > > Best, > > Jeff > -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Jeff Hammond 09 Mar '15

09 Mar '15

I know some of you like warning-clean builds... ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] return bitarray; ^~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] return bitarray; ^~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] bitarray = group_to_bitarray(local_fail, comm_ptr); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 warnings generated. Best, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] [hwloc-devel] Build failure in OS X, libxml required?
by Lisandro Dalcin 07 Mar '15

07 Mar '15

OK, I finally figured out what's going on. I recently upgraded to Mac OS X Yosemite, and I did not install the Xcode command line tools. My /usr/include directory was missing, however I had /usr/bin/clang (not sure wether it is there because of the default Xcode install, or it was a leftover of my previous OS X system). I also had pkg-config installed trough Homebrew, and "pkg-config --cflags libxml-2.0" prints "-I/usr/include/libxml2", however remember I did not have "/usr/include". Do this pkg-config install is assuming /usr/include do exist. The thing is that MPICH is able to build fine (and in fact, many other software packages) as long as you pass --disable-libxml2 to workaround the hwloc issue. But after spending some time looking at hwloc build system, I realized the dependence on pkg-config to look for libxml2, and then there is no easy workaround. Finally, I've installed the Xcode command line tools (with "xcode-select --install") and MPICH + embed hwloc built just fine. Now I had the cmd line tools in my system, but it makes sense anyway, after all I use it everyday for development and the lack of it will likely cause me headaches in the near future with some other software. Some final comment for hwloc folks: * Relying in pkg-config for building is totally fine, but please note this tool is non-standard in OS X. * Looking in config/hwloc_pkg.m4, I noticed you somehow do check for broken stuff by attempting to link with package libraries. Well, if would be nice to extend this macro to also check you are able to compile by #include'ing package headers. IMHO, such sanity checks save time in the long run for both developer and users. Sorry I do not offer a patch, I have very limited knowledge of autotools and M4. On 7 March 2015 at 00:24, Brice Goglin <Brice.Goglin(a)inria.fr> wrote: > Hello, > > Sorry but we don't add configure checks without knowing what's causing > the problem. So far it only looks like a broken libxml install. > > We cannot check for all broken installs in the world. Otherwise one day > somebody will remove printf from his libc and request a new configure > check for printf() as well. And another check in case he modified > printf() to return different values. And another check in case printf() > was renamed to pruntf(). Endless. > > Please try to understand what caused this broken/partial libxml install > (do you have logs of the install?). > > By the way, let's make this new hwloc feature official: hwloc can now > detect broken libxml installs by failing to build :) > > Brice > > > > > > Le 06/03/2015 21:14, Balaji, Pavan a écrit : >> Hi, >> >> This is a problem with hwloc, which I had reported in the past. I believe this is not fixed in hwloc yet. >> >> The suggestion given at that point was to remove and install libxml again, which I did, and things started working correctly again. But, I agree, hwloc should detect this in configure and abort if there's an issue. >> >> I've cc'ed hwloc-devel. >> >> -- Pavan >> >>> On Mar 6, 2015, at 2:10 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >>> >>> This is with the 3.1.4 tarball. Not sure if this is actually a problem >>> in MPICH or in my system. >>> >>> I got the following build failure. Shouldn't configure catch that beforehand? >>> >>> Making all in tools/topo/hwloc/hwloc >>> Making all in src >>> CC topology.lo >>> CC traversal.lo >>> CC distances.lo >>> CC components.lo >>> CC bind.lo >>> CC bitmap.lo >>> CC pci-common.lo >>> CC diff.lo >>> CC misc.lo >>> CC base64.lo >>> CC topology-noos.lo >>> CC topology-synthetic.lo >>> CC topology-custom.lo >>> CC topology-xml.lo >>> CC topology-xml-nolibxml.lo >>> CC topology-xml-libxml.lo >>> CC topology-darwin.lo >>> CC topology-x86.lo >>> topology-xml-libxml.c:17:10: fatal error: 'libxml/parser.h' file not found >>> #include <libxml/parser.h> >>> ^ >>> 1 error generated. >>> make[4]: *** [topology-xml-libxml.lo] Error 1 >>> make[4]: *** Waiting for unfinished jobs.... >>> make[3]: *** [all-recursive] Error 1 >>> make[2]: *** [all-recursive] Error 1 >>> make[1]: *** [all-recursive] Error 1 >>> make: *** [all] Error 2 >>> >>> >>> -- >>> Lisandro Dalcin >>> ============ >>> Research Scientist >>> Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) >>> Numerical Porous Media Center (NumPor) >>> King Abdullah University of Science and Technology (KAUST) >>> http://numpor.kaust.edu.sa/ >>> >>> 4700 King Abdullah University of Science and Technology >>> al-Khawarizmi Bldg (Bldg 1), Office # 4332 >>> Thuwal 23955-6900, Kingdom of Saudi Arabia >>> http://www.kaust.edu.sa >>> >>> Office Phone: +966 12 808-0459 >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> -- >> Pavan Balaji ✉️ >> http://www.mcs.anl.gov/~balaji >> >> _______________________________________________ >> hwloc-devel mailing list >> hwloc-devel(a)open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel >> Link to this post: http://www.open-mpi.org/community/lists/hwloc-devel/2015/03/4400.php > -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0

Re: [mpich-devel] Build failure in OS X, libxml required?
by Balaji, Pavan 06 Mar '15

06 Mar '15

Hi, This is a problem with hwloc, which I had reported in the past. I believe this is not fixed in hwloc yet. The suggestion given at that point was to remove and install libxml again, which I did, and things started working correctly again. But, I agree, hwloc should detect this in configure and abort if there's an issue. I've cc'ed hwloc-devel. -- Pavan > On Mar 6, 2015, at 2:10 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > This is with the 3.1.4 tarball. Not sure if this is actually a problem > in MPICH or in my system. > > I got the following build failure. Shouldn't configure catch that beforehand? > > Making all in tools/topo/hwloc/hwloc > Making all in src > CC topology.lo > CC traversal.lo > CC distances.lo > CC components.lo > CC bind.lo > CC bitmap.lo > CC pci-common.lo > CC diff.lo > CC misc.lo > CC base64.lo > CC topology-noos.lo > CC topology-synthetic.lo > CC topology-custom.lo > CC topology-xml.lo > CC topology-xml-nolibxml.lo > CC topology-xml-libxml.lo > CC topology-darwin.lo > CC topology-x86.lo > topology-xml-libxml.c:17:10: fatal error: 'libxml/parser.h' file not found > #include <libxml/parser.h> > ^ > 1 error generated. > make[4]: *** [topology-xml-libxml.lo] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > -- > Lisandro Dalcin > ============ > Research Scientist > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > Numerical Porous Media Center (NumPor) > King Abdullah University of Science and Technology (KAUST) > http://numpor.kaust.edu.sa/ > > 4700 King Abdullah University of Science and Technology > al-Khawarizmi Bldg (Bldg 1), Office # 4332 > Thuwal 23955-6900, Kingdom of Saudi Arabia > http://www.kaust.edu.sa > > Office Phone: +966 12 808-0459 > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] patch for ticket #1526 (MPI_Alloc_mem registered memory)
by Zhao, Xin 06 Mar '15

06 Mar '15

Hi Steffen, Thank you very much for your contribution. We pushed your patch into MPICH (03d4c77b2148769436b8ce0b682b9b7a662baeef) with some modification. You can directly check it from our repo: git.mpich.org/mpich.git. Thanks, Xin ________________________________________ From: Steffen Christgau [christgau(a)cs.uni-potsdam.de] Sent: Tuesday, January 20, 2015 7:57 AM To: devel(a)mpich.org Subject: [mpich-devel] patch for ticket #1526 (MPI_Alloc_mem registered memory) Hi, I'm currently going to improve the RMA operations (and only those) of an existing CH3 channel for the underlying hardware in a local development branch of MPICH. I appreciate the feature to override the window creation functions in the channel implementation, and the possibility to override the RMA functions via the function table associated to each window. These together simplify development a lot. As one can override the OSC/RMA functions, I really wonder why it is not possible to do the same with the implementation of MPI_Alloc_mem at a CH3 channel level. I found that there was an attempt to introduce this in ticket #1526. Although the original ticket points at a slightly different spot, the discussion is about the issue I'm currently facing. Anyways, it seems to be dormant for a long time and I was not able to find traces of the OSC branch mentioned in the comments (likely that is has been merged into master or it is lost in history) where a solution for this issue was presented according to the comment. That said, I'd like to propose a patch to allow a channel implementation to provide a custom implementation of MPI_Alloc_mem resp. MPI_Free_mem. The idea is borrowed from MPIDI_CH3_Channel_close() which is declared if the MPIDI_CH3_HAS_CHANNEL_CLOSE macro is defined or falls back to the default preprocessor macro "implementation". Same thing here: if according macros are defined, the channel provides an implementation. If not, the defaults are used, i.e. the current MPIU-calls. The CH3 device implementation had to be adjusted to account these changes. As the solution falls back to macro substitution by default, I don't expect any performance impacts, broken code or test failures for existing channel devices. The RMA test cases succeeded both for the my channel device as they did before. The patch (see attachment as well) is based on the v3.1.3 tag. Maybe it helps other implementers (if there's any ;-)) to integrate the allocation of special memory into their channel. diff --git a/src/mpid/ch3/include/mpidimpl.h b/src/mpid/ch3/include/mpidimpl.h index 6a9db2d..1b0ae17 100644 --- a/src/mpid/ch3/include/mpidimpl.h +++ b/src/mpid/ch3/include/mpidimpl.h @@ -1222,6 +1222,19 @@ int MPIDI_Win_sync(MPID_Win *win); void *MPIDI_Alloc_mem(size_t size, MPID_Info *info_ptr); int MPIDI_Free_mem(void *ptr); +#ifdef MPIDI_CH3_HAS_ALLOC_MEM +void* MPIDI_CH3_Alloc_mem(size_t size, MPID_Info *info_ptr); +/* fallback to MPIU_Malloc if channel does not have its own RMA memory allocator */ +#else +#define MPIDI_CH3_Alloc_mem(size, info_ptr) MPIU_Malloc(size) +#endif + +#ifdef MPIDI_CH3_HAS_FREE_MEM +int MPIDI_Free_mem(void *ptr); +#else +#define MPIDI_CH3_Free_mem(ptr) MPIU_Free(ptr); +#endif + /* Pvars */ void MPIDI_CH3_RMA_Init_Pvars(void); diff --git a/src/mpid/ch3/src/ch3u_rma_ops.c b/src/mpid/ch3/src/ch3u_rma_ops.c index f30c464..7a3e22b 100644 --- a/src/mpid/ch3/src/ch3u_rma_ops.c +++ b/src/mpid/ch3/src/ch3u_rma_ops.c @@ -472,7 +472,7 @@ void *MPIDI_Alloc_mem( size_t size, MPID_Info *info_ptr ) MPIDI_FUNC_ENTER(MPID_STATE_MPIDI_ALLOC_MEM); - ap = MPIU_Malloc(size); + ap = MPIDI_CH3_Alloc_mem(size, info_ptr); MPIDI_FUNC_EXIT(MPID_STATE_MPIDI_ALLOC_MEM); return ap; @@ -490,7 +490,7 @@ int MPIDI_Free_mem( void *ptr ) MPIDI_FUNC_ENTER(MPID_STATE_MPIDI_FREE_MEM); - MPIU_Free(ptr); + MPIDI_CH3_Free_mem(ptr); MPIDI_FUNC_EXIT(MPID_STATE_MPIDI_FREE_MEM); return mpi_errno; Regards, Steffen

1 0

Re: [mpich-devel] Build failure in OS X, libxml required?
by Jeff Hammond 06 Mar '15

06 Mar '15

Write hwloc list for details... Jeff Sent from my iPhone > On Mar 6, 2015, at 12:10 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > This is with the 3.1.4 tarball. Not sure if this is actually a problem > in MPICH or in my system. > > I got the following build failure. Shouldn't configure catch that beforehand? > > Making all in tools/topo/hwloc/hwloc > Making all in src > CC topology.lo > CC traversal.lo > CC distances.lo > CC components.lo > CC bind.lo > CC bitmap.lo > CC pci-common.lo > CC diff.lo > CC misc.lo > CC base64.lo > CC topology-noos.lo > CC topology-synthetic.lo > CC topology-custom.lo > CC topology-xml.lo > CC topology-xml-nolibxml.lo > CC topology-xml-libxml.lo > CC topology-darwin.lo > CC topology-x86.lo > topology-xml-libxml.c:17:10: fatal error: 'libxml/parser.h' file not found > #include <libxml/parser.h> > ^ > 1 error generated. > make[4]: *** [topology-xml-libxml.lo] Error 1 > make[4]: *** Waiting for unfinished jobs.... > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > -- > Lisandro Dalcin > ============ > Research Scientist > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > Numerical Porous Media Center (NumPor) > King Abdullah University of Science and Technology (KAUST) > http://numpor.kaust.edu.sa/ > > 4700 King Abdullah University of Science and Technology > al-Khawarizmi Bldg (Bldg 1), Office # 4332 > Thuwal 23955-6900, Kingdom of Saudi Arabia > http://www.kaust.edu.sa > > Office Phone: +966 12 808-0459 > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Build failure in OS X, libxml required?
by Lisandro Dalcin 06 Mar '15

06 Mar '15

This is with the 3.1.4 tarball. Not sure if this is actually a problem in MPICH or in my system. I got the following build failure. Shouldn't configure catch that beforehand? Making all in tools/topo/hwloc/hwloc Making all in src CC topology.lo CC traversal.lo CC distances.lo CC components.lo CC bind.lo CC bitmap.lo CC pci-common.lo CC diff.lo CC misc.lo CC base64.lo CC topology-noos.lo CC topology-synthetic.lo CC topology-custom.lo CC topology-xml.lo CC topology-xml-nolibxml.lo CC topology-xml-libxml.lo CC topology-darwin.lo CC topology-x86.lo topology-xml-libxml.c:17:10: fatal error: 'libxml/parser.h' file not found #include <libxml/parser.h> ^ 1 error generated. make[4]: *** [topology-xml-libxml.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [all-recursive] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 -- Lisandro Dalcin ============ Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 King Abdullah University of Science and Technology al-Khawarizmi Bldg (Bldg 1), Office # 4332 Thuwal 23955-6900, Kingdom of Saudi Arabia http://www.kaust.edu.sa Office Phone: +966 12 808-0459

1 0