December 2012 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by Jeff Hammond 31 Dec '12

31 Dec '12

I'll file a ticket for Dave to track this. Jeff $ svn info ../src/mpi/datatype/status_set_elements_x.c Path: ../src/mpi/datatype/status_set_elements_x.c Name: status_set_elements_x.c URL: https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/src/mpi/datatype/status_set_… Repository Root: https://svn.mcs.anl.gov/repos/mpi Repository UUID: a5d90c62-d51d-0410-9f91-bf5351168976 Revision: 10808 Node Kind: file Schedule: normal Last Changed Author: goodell Last Changed Rev: 10562 Last Changed Date: 2012-11-06 23:30:35 -0600 (Tue, 06 Nov 2012) Text Last Updated: 2012-12-31 13:12:28 -0600 (Mon, 31 Dec 2012) Checksum: d6aaaab0ac7a798169e2678bca3e1805 On Mon, Dec 31, 2012 at 2:33 PM, William Gropp <wgropp(a)illinois.edu> wrote: > Ah, that's a different problem - that's an error in the implementation file, which is incorrectly assuming that LLONG_MAX is always defined. That needs to be fixed by the routine's author. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 31, 2012, at 2:19 PM, Jeff Hammond wrote: > >> This is my setup and what I see: >> >> [jhammond@flogin3 build-gcc]$ uname -a >> Linux flogin3 2.6.18-274.18.1.el5 #1 SMP Fri Jan 20 15:11:18 EST 2012 >> x86_64 x86_64 x86_64 GNU/Linux >> >> [jhammond@flogin3 build-gcc]$ svn info .. >> Path: .. >> URL: https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk >> Repository Root: https://svn.mcs.anl.gov/repos/mpi >> Repository UUID: a5d90c62-d51d-0410-9f91-bf5351168976 >> Revision: 10808 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: dinan >> Last Changed Rev: 10808 >> Last Changed Date: 2012-12-28 22:21:55 -0600 (Fri, 28 Dec 2012) >> >> [jhammond@flogin3 build-gcc]$ which gcc >> /soft/gcc/4.4.2/bin/gcc >> >> [jhammond@flogin3 build-gcc]$ gcc --version >> gcc (GCC) 4.4.2 >> Copyright (C) 2009 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> [jhammond@flogin3 build-gcc]$ ../configure --enable-threads --enable-g >> --prefix=/homes/jhammond/MPI/mpich2-trunk/install-gcc && make -j8 && >> make install >> <snip> >> CC src/mpi_t/mpi_t_util.lo >> CC src/nameserv/file/file_nameserv.lo >> CC src/pmi/simple/simple_pmiutil.lo >> CC src/pmi/simple/simple_pmi.lo >> CC src/mpi/datatype/status_set_elements_x.lo >> CC src/mpi/datatype/type_indexed.lo >> CC src/mpi/datatype/type_hindexed.lo >> CC src/mpi/datatype/type_struct.lo >> CC src/mpi/datatype/type_contiguous.lo >> CC src/mpi/datatype/type_free.lo >> CC src/mpi/datatype/type_hvector.lo >> ../src/mpi/datatype/status_set_elements_x.c: In function >> 'MPIR_Status_set_elements_x_impl': >> ../src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' >> undeclared (first use in this function) >> ../src/mpi/datatype/status_set_elements_x.c:41: error: (Each >> undeclared identifier is reported only once >> ../src/mpi/datatype/status_set_elements_x.c:41: error: for each >> function it appears in.) >> make[2]: *** [src/mpi/datatype/status_set_elements_x.lo] Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make[2]: Leaving directory >> `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory >> `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' >> make: *** [all] Error 2 >> >> Jeff >> >> On Mon, Dec 31, 2012 at 2:07 PM, William Gropp <wgropp(a)illinois.edu> wrote: >>> I've committed the change that tests for LLONG_MAX - in r10802 . What error are you seeing? >>> >>> Bill >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> On Dec 31, 2012, at 1:37 PM, Jeff Hammond wrote: >>> >>>> I did a fresh checkout today and am still seeing this issue. What's >>>> the workaround until it is fixed for real? >>>> >>>> I am working on Fusion at Argonne using "../configure --enable-threads >>>> --enable-g" and GCC 4.4.2 compilers, btw. >>>> >>>> Thanks, >>>> >>>> Jeff >>>> >>>> On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: >>>>> Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. >>>>> >>>>> Bill >>>>> >>>>> William Gropp >>>>> Director, Parallel Computing Institute >>>>> Deputy Director for Research >>>>> Institute for Advanced Computing Applications and Technologies >>>>> Paul and Cynthia Saylor Professor of Computer Science >>>>> University of Illinois Urbana-Champaign >>>>> >>>>> >>>>> >>>>> On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: >>>>> >>>>>> Hello Howard, >>>>>> I have encountered the same problem with mpich-3.0.1 today. (And >>>>>> that's why I found this thread :P) >>>>>> After raising the optimization level, it didn't complain about that >>>>>> undeclared problem anymore, and the installation goes well. >>>>>> This is my configure option: >>>>>> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >>>>>> >>>>>> BTW, the problem still exist for "indexed-misc.c" under the test directory >>>>>> >>>>>> Regards >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeff Hammond >>>> Argonne Leadership Computing Facility >>>> University of Chicago Computation Institute >>>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>>> http://www.linkedin.com/in/jeffhammond >>>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >>> >> >> >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by William Gropp 31 Dec '12

31 Dec '12

Ah, that's a different problem - that's an error in the implementation file, which is incorrectly assuming that LLONG_MAX is always defined. That needs to be fixed by the routine's author. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 31, 2012, at 2:19 PM, Jeff Hammond wrote: > This is my setup and what I see: > > [jhammond@flogin3 build-gcc]$ uname -a > Linux flogin3 2.6.18-274.18.1.el5 #1 SMP Fri Jan 20 15:11:18 EST 2012 > x86_64 x86_64 x86_64 GNU/Linux > > [jhammond@flogin3 build-gcc]$ svn info .. > Path: .. > URL: https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk > Repository Root: https://svn.mcs.anl.gov/repos/mpi > Repository UUID: a5d90c62-d51d-0410-9f91-bf5351168976 > Revision: 10808 > Node Kind: directory > Schedule: normal > Last Changed Author: dinan > Last Changed Rev: 10808 > Last Changed Date: 2012-12-28 22:21:55 -0600 (Fri, 28 Dec 2012) > > [jhammond@flogin3 build-gcc]$ which gcc > /soft/gcc/4.4.2/bin/gcc > > [jhammond@flogin3 build-gcc]$ gcc --version > gcc (GCC) 4.4.2 > Copyright (C) 2009 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > [jhammond@flogin3 build-gcc]$ ../configure --enable-threads --enable-g > --prefix=/homes/jhammond/MPI/mpich2-trunk/install-gcc && make -j8 && > make install > <snip> > CC src/mpi_t/mpi_t_util.lo > CC src/nameserv/file/file_nameserv.lo > CC src/pmi/simple/simple_pmiutil.lo > CC src/pmi/simple/simple_pmi.lo > CC src/mpi/datatype/status_set_elements_x.lo > CC src/mpi/datatype/type_indexed.lo > CC src/mpi/datatype/type_hindexed.lo > CC src/mpi/datatype/type_struct.lo > CC src/mpi/datatype/type_contiguous.lo > CC src/mpi/datatype/type_free.lo > CC src/mpi/datatype/type_hvector.lo > ../src/mpi/datatype/status_set_elements_x.c: In function > 'MPIR_Status_set_elements_x_impl': > ../src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' > undeclared (first use in this function) > ../src/mpi/datatype/status_set_elements_x.c:41: error: (Each > undeclared identifier is reported only once > ../src/mpi/datatype/status_set_elements_x.c:41: error: for each > function it appears in.) > make[2]: *** [src/mpi/datatype/status_set_elements_x.lo] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[2]: Leaving directory > `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' > make: *** [all] Error 2 > > Jeff > > On Mon, Dec 31, 2012 at 2:07 PM, William Gropp <wgropp(a)illinois.edu> wrote: >> I've committed the change that tests for LLONG_MAX - in r10802 . What error are you seeing? >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 31, 2012, at 1:37 PM, Jeff Hammond wrote: >> >>> I did a fresh checkout today and am still seeing this issue. What's >>> the workaround until it is fixed for real? >>> >>> I am working on Fusion at Argonne using "../configure --enable-threads >>> --enable-g" and GCC 4.4.2 compilers, btw. >>> >>> Thanks, >>> >>> Jeff >>> >>> On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: >>>> Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. >>>> >>>> Bill >>>> >>>> William Gropp >>>> Director, Parallel Computing Institute >>>> Deputy Director for Research >>>> Institute for Advanced Computing Applications and Technologies >>>> Paul and Cynthia Saylor Professor of Computer Science >>>> University of Illinois Urbana-Champaign >>>> >>>> >>>> >>>> On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: >>>> >>>>> Hello Howard, >>>>> I have encountered the same problem with mpich-3.0.1 today. (And >>>>> that's why I found this thread :P) >>>>> After raising the optimization level, it didn't complain about that >>>>> undeclared problem anymore, and the installation goes well. >>>>> This is my configure option: >>>>> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >>>>> >>>>> BTW, the problem still exist for "indexed-misc.c" under the test directory >>>>> >>>>> Regards >>>> >>> >>> >>> >>> -- >>> Jeff Hammond >>> Argonne Leadership Computing Facility >>> University of Chicago Computation Institute >>> jhammond(a)alcf.anl.gov / (630) 252-5381 >>> http://www.linkedin.com/in/jeffhammond >>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond >> > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by Jeff Hammond 31 Dec '12

31 Dec '12

This is my setup and what I see: [jhammond@flogin3 build-gcc]$ uname -a Linux flogin3 2.6.18-274.18.1.el5 #1 SMP Fri Jan 20 15:11:18 EST 2012 x86_64 x86_64 x86_64 GNU/Linux [jhammond@flogin3 build-gcc]$ svn info .. Path: .. URL: https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk Repository Root: https://svn.mcs.anl.gov/repos/mpi Repository UUID: a5d90c62-d51d-0410-9f91-bf5351168976 Revision: 10808 Node Kind: directory Schedule: normal Last Changed Author: dinan Last Changed Rev: 10808 Last Changed Date: 2012-12-28 22:21:55 -0600 (Fri, 28 Dec 2012) [jhammond@flogin3 build-gcc]$ which gcc /soft/gcc/4.4.2/bin/gcc [jhammond@flogin3 build-gcc]$ gcc --version gcc (GCC) 4.4.2 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [jhammond@flogin3 build-gcc]$ ../configure --enable-threads --enable-g --prefix=/homes/jhammond/MPI/mpich2-trunk/install-gcc && make -j8 && make install <snip> CC src/mpi_t/mpi_t_util.lo CC src/nameserv/file/file_nameserv.lo CC src/pmi/simple/simple_pmiutil.lo CC src/pmi/simple/simple_pmi.lo CC src/mpi/datatype/status_set_elements_x.lo CC src/mpi/datatype/type_indexed.lo CC src/mpi/datatype/type_hindexed.lo CC src/mpi/datatype/type_struct.lo CC src/mpi/datatype/type_contiguous.lo CC src/mpi/datatype/type_free.lo CC src/mpi/datatype/type_hvector.lo ../src/mpi/datatype/status_set_elements_x.c: In function 'MPIR_Status_set_elements_x_impl': ../src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' undeclared (first use in this function) ../src/mpi/datatype/status_set_elements_x.c:41: error: (Each undeclared identifier is reported only once ../src/mpi/datatype/status_set_elements_x.c:41: error: for each function it appears in.) make[2]: *** [src/mpi/datatype/status_set_elements_x.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/fusion/gpfs/home/jhammond/MPI/mpich2-trunk/build-gcc' make: *** [all] Error 2 Jeff On Mon, Dec 31, 2012 at 2:07 PM, William Gropp <wgropp(a)illinois.edu> wrote: > I've committed the change that tests for LLONG_MAX - in r10802 . What error are you seeing? > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 31, 2012, at 1:37 PM, Jeff Hammond wrote: > >> I did a fresh checkout today and am still seeing this issue. What's >> the workaround until it is fixed for real? >> >> I am working on Fusion at Argonne using "../configure --enable-threads >> --enable-g" and GCC 4.4.2 compilers, btw. >> >> Thanks, >> >> Jeff >> >> On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: >>> Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. >>> >>> Bill >>> >>> William Gropp >>> Director, Parallel Computing Institute >>> Deputy Director for Research >>> Institute for Advanced Computing Applications and Technologies >>> Paul and Cynthia Saylor Professor of Computer Science >>> University of Illinois Urbana-Champaign >>> >>> >>> >>> On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: >>> >>>> Hello Howard, >>>> I have encountered the same problem with mpich-3.0.1 today. (And >>>> that's why I found this thread :P) >>>> After raising the optimization level, it didn't complain about that >>>> undeclared problem anymore, and the installation goes well. >>>> This is my configure option: >>>> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >>>> >>>> BTW, the problem still exist for "indexed-misc.c" under the test directory >>>> >>>> Regards >>> >> >> >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
by Jeff Hammond 31 Dec '12

31 Dec '12

I don't disagree at all with your reasoning here and would certainly favor the definition of __USE_GNU at the top level, but that's a much more invasive change. The Linux kernel documentation http://www.kernel.org/doc/man-pages/online/pages/man3/CPU_SET.3.html demonstrates the usage that is currently in MPICH as well as in numerous examples on the Internet... Best, Jeff On Mon, Dec 31, 2012 at 2:12 PM, William Gropp <wgropp(a)illinois.edu> wrote: > For many cases like this, the best solution is either > > Never use any macro that starts with __ (these should be reserved "for the system") > > If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case). > > Adding it to any other header file should always be considered a mistake. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote: > >> Having been frustrated in a related development effort because I was >> unaware that sched.h was previously and indirectly included without >> the __USE_GNU macro active, thereby preventing me from using CPU_ZERO >> and CPU_SET, I suggest the inclusion of the following preprocessor >> macro in MPICH so that it is plainly obvious should this occur in the >> future due to the prior inclusion of sched.h before the following >> code, which is actually quite far down in the source. >> >> I recognize that this is currently not a problem nor is the code below >> even active right now, but (1) should it ever be active and (2) some >> developer includes sched.h without __USE_GNU prior to line 1050 in >> this file (there are ~10 MPICH internal headers that could cause this >> right now), there will be a problem that is only detected when e.g. >> cpi is linked, which is later than one would otherwise prefer. >> >> Best, >> >> Jeff >> >> $ svn diff pm/util/process.c >> Index: pm/util/process.c >> =================================================================== >> --- pm/util/process.c (revision 10808) >> +++ pm/util/process.c (working copy) >> @@ -1031,6 +1031,11 @@ >> #define __USE_GNU >> #endif >> #include <sched.h> >> + >> +#if !defined(CPU_ZERO) || !defined(CPU_SET) >> +#error CPU_ZERO and/or CPU_SET were not defined because of prior >> inclusion of sched.h without __USE_GNU >> +#endif >> + >> /* >> * Set the processor affinity for the calling process. Normally, this will >> * be used in the "postfork" routine provided by the process manager, before >> >> -- >> Jeff Hammond >> Argonne Leadership Computing Facility >> University of Chicago Computation Institute >> jhammond(a)alcf.anl.gov / (630) 252-5381 >> http://www.linkedin.com/in/jeffhammond >> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] helpful preprocessor check for CPU_ZERO and CPU_SET
by William Gropp 31 Dec '12

31 Dec '12

For many cases like this, the best solution is either Never use any macro that starts with __ (these should be reserved "for the system") If you must, it needs to be defined early, including *before* any configure tests on capabilities of the headers or the compiler, since these macros (e.g., __USE_GNU etc.) *change* the language that is implemented. It is a serious error to define this within any header file, other than the configuration file (mpichconf.h in our case). Adding it to any other header file should always be considered a mistake. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 31, 2012, at 12:54 PM, Jeff Hammond wrote: > Having been frustrated in a related development effort because I was > unaware that sched.h was previously and indirectly included without > the __USE_GNU macro active, thereby preventing me from using CPU_ZERO > and CPU_SET, I suggest the inclusion of the following preprocessor > macro in MPICH so that it is plainly obvious should this occur in the > future due to the prior inclusion of sched.h before the following > code, which is actually quite far down in the source. > > I recognize that this is currently not a problem nor is the code below > even active right now, but (1) should it ever be active and (2) some > developer includes sched.h without __USE_GNU prior to line 1050 in > this file (there are ~10 MPICH internal headers that could cause this > right now), there will be a problem that is only detected when e.g. > cpi is linked, which is later than one would otherwise prefer. > > Best, > > Jeff > > $ svn diff pm/util/process.c > Index: pm/util/process.c > =================================================================== > --- pm/util/process.c (revision 10808) > +++ pm/util/process.c (working copy) > @@ -1031,6 +1031,11 @@ > #define __USE_GNU > #endif > #include <sched.h> > + > +#if !defined(CPU_ZERO) || !defined(CPU_SET) > +#error CPU_ZERO and/or CPU_SET were not defined because of prior > inclusion of sched.h without __USE_GNU > +#endif > + > /* > * Set the processor affinity for the calling process. Normally, this will > * be used in the "postfork" routine provided by the process manager, before > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by William Gropp 31 Dec '12

31 Dec '12

I've committed the change that tests for LLONG_MAX - in r10802 . What error are you seeing? Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 31, 2012, at 1:37 PM, Jeff Hammond wrote: > I did a fresh checkout today and am still seeing this issue. What's > the workaround until it is fixed for real? > > I am working on Fusion at Argonne using "../configure --enable-threads > --enable-g" and GCC 4.4.2 compilers, btw. > > Thanks, > > Jeff > > On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: >> Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. >> >> Bill >> >> William Gropp >> Director, Parallel Computing Institute >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: >> >>> Hello Howard, >>> I have encountered the same problem with mpich-3.0.1 today. (And >>> that's why I found this thread :P) >>> After raising the optimization level, it didn't complain about that >>> undeclared problem anymore, and the installation goes well. >>> This is my configure option: >>> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >>> >>> BTW, the problem still exist for "indexed-misc.c" under the test directory >>> >>> Regards >> > > > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by Jeff Hammond 31 Dec '12

31 Dec '12

I did a fresh checkout today and am still seeing this issue. What's the workaround until it is fixed for real? I am working on Fusion at Argonne using "../configure --enable-threads --enable-g" and GCC 4.4.2 compilers, btw. Thanks, Jeff On Fri, Dec 21, 2012 at 8:22 AM, William Gropp <wgropp(a)illinois.edu> wrote: > Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. > > Bill > > William Gropp > Director, Parallel Computing Institute > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: > >> Hello Howard, >> I have encountered the same problem with mpich-3.0.1 today. (And >> that's why I found this thread :P) >> After raising the optimization level, it didn't complain about that >> undeclared problem anymore, and the installation goes well. >> This is my configure option: >> ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 >> >> BTW, the problem still exist for "indexed-misc.c" under the test directory >> >> Regards > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

helpful preprocessor check for CPU_ZERO and CPU_SET
by Jeff Hammond 31 Dec '12

31 Dec '12

Having been frustrated in a related development effort because I was unaware that sched.h was previously and indirectly included without the __USE_GNU macro active, thereby preventing me from using CPU_ZERO and CPU_SET, I suggest the inclusion of the following preprocessor macro in MPICH so that it is plainly obvious should this occur in the future due to the prior inclusion of sched.h before the following code, which is actually quite far down in the source. I recognize that this is currently not a problem nor is the code below even active right now, but (1) should it ever be active and (2) some developer includes sched.h without __USE_GNU prior to line 1050 in this file (there are ~10 MPICH internal headers that could cause this right now), there will be a problem that is only detected when e.g. cpi is linked, which is later than one would otherwise prefer. Best, Jeff $ svn diff pm/util/process.c Index: pm/util/process.c =================================================================== --- pm/util/process.c (revision 10808) +++ pm/util/process.c (working copy) @@ -1031,6 +1031,11 @@ #define __USE_GNU #endif #include <sched.h> + +#if !defined(CPU_ZERO) || !defined(CPU_SET) +#error CPU_ZERO and/or CPU_SET were not defined because of prior inclusion of sched.h without __USE_GNU +#endif + /* * Set the processor affinity for the calling process. Normally, this will * be used in the "postfork" routine provided by the process manager, before -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by William Gropp 27 Dec '12

27 Dec '12

We all agree that the language can be tightened up. The approach taken was to specify what was required (commit for communication) and then point out that one important case where commit is not required is the case of datatype construction. It is also extraordinarily dangerous to claim to cover all cases in the text - this is almost always doomed to failure. Best is to do what you can and then rely on a consistent reading of the text. Perhaps a better fix is to say that a commit is *only* required for datatypes used in communication. Emphasize that in other cases, such as constructing a datatype, a commit is not required. That is certainly the sense that was intended. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 27, 2012, at 2:35 PM, Jeff Hammond wrote: >> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >>> The standard is already clear - commit is only required when the >>> datatype is used for communication. It is unnecessary for the >>> standard to list all cases where commit is not required - it is >>> enough to list where commit *is* required, which it does. > > This is argument of the form "unless something is explicitly > prohibited, it is permitted," which is extraordinarily dangerous and > inconsistent with a robust standards document. > >> The way the text is currently written, it says "it is required for case >> X and not required for case Y" instead of saying "not required for all >> other cases". If the intended behavior is to not throw an error for >> non-communication routines, then the one example (of datatype >> constructors) should be removed from the standard, or just rewritten as >> "other operations such as datatype constructors". > > Exactly. The sentence "As an argument in datatype constructors, > uncommitted and also committed datatypes > can be used," should be removed completely or otherwise modified such > that there is no potential for it to be misinterpreted as an exclusive > list of permitted usage. > > Jeff > > -- > Jeff Hammond > Argonne Leadership Computing Facility > University of Chicago Computation Institute > jhammond(a)alcf.anl.gov / (630) 252-5381 > http://www.linkedin.com/in/jeffhammond > https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Jeff Hammond 27 Dec '12

27 Dec '12

> On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: >> The standard is already clear - commit is only required when the >> datatype is used for communication. It is unnecessary for the >> standard to list all cases where commit is not required - it is >> enough to list where commit *is* required, which it does. This is argument of the form "unless something is explicitly prohibited, it is permitted," which is extraordinarily dangerous and inconsistent with a robust standards document. > The way the text is currently written, it says "it is required for case > X and not required for case Y" instead of saying "not required for all > other cases". If the intended behavior is to not throw an error for > non-communication routines, then the one example (of datatype > constructors) should be removed from the standard, or just rewritten as > "other operations such as datatype constructors". Exactly. The sentence "As an argument in datatype constructors, uncommitted and also committed datatypes can be used," should be removed completely or otherwise modified such that there is no potential for it to be misinterpreted as an exclusive list of permitted usage. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0