July 2013 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] hwloc build failing on Mac with GCC
by Jeff Hammond 31 Jul '13

31 Jul '13

How different is 11.4.2 from 10.7.4? Seems like a big diff in the OS dimension. I'd really like to try to narrow this down because I'm currently blocked on this w.r.t. an app I'm trying to run. Jeff ----- Original Message ----- > From: "Ken Raffenetti" <raffenet(a)mcs.anl.gov> > To: devel(a)mpich.org > Sent: Wednesday, July 31, 2013 5:40:55 PM > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > I'll just note that building on our OSX 10.7.4 test environment > doesn't show any issues in this configuration. > > ----- Original Message ----- > > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > > To: devel(a)mpich.org > > Sent: Wednesday, July 31, 2013 4:00:59 PM > > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > > > Yes, that's right. Sorry. It's attached. > > > > Jeff > > > > ----- Original Message ----- > > > From: "Ken Raffenetti" <raffenet(a)mcs.anl.gov> > > > To: devel(a)mpich.org > > > Sent: Wednesday, July 31, 2013 3:51:01 PM > > > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > > > > > Maybe I'm missing something, but I fail to find a problem in the > > > attachment. Did you mean to attach a make log? > > > > > > ----- Original Message ----- > > > > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > > > > To: "MPICH" <devel(a)mpich.org> > > > > Sent: Wednesday, July 31, 2013 2:43:55 PM > > > > Subject: [mpich-devel] hwloc build failing on Mac with GCC > > > > > > > > Am I stupid or is something broken? This is the git head as of > > > > a > > > > few > > > > minutes ago. > > > > > > > > Note that the essence of the problem is in the attachment. I > > > > will > > > > not > > > > repeat it here. > > > > > > > > Thanks, > > > > > > > > Jeff > > > > > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ gcc -v > > > > Using built-in specs. > > > > COLLECT_GCC=gcc > > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > > Target: x86_64-apple-darwin11 > > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > > --build=x86_64-apple-darwin11 > > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > > --libdir=/opt/local/lib/gcc48 > > > > --includedir=/opt/local/include/gcc48 > > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > > --datarootdir=/opt/local/share/gcc-4.8 > > > > --with-local-prefix=/opt/local > > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > > --with-mpc=/opt/local > > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > > --enable-stage1-checking --disable-multilib --enable-lto > > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > > --with-bugurl=https://trac.macports.org/newticket > > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > > Thread model: posix > > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ g++ -v > > > > Using built-in specs. > > > > COLLECT_GCC=g++ > > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > > Target: x86_64-apple-darwin11 > > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > > --build=x86_64-apple-darwin11 > > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > > --libdir=/opt/local/lib/gcc48 > > > > --includedir=/opt/local/include/gcc48 > > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > > --datarootdir=/opt/local/share/gcc-4.8 > > > > --with-local-prefix=/opt/local > > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > > --with-mpc=/opt/local > > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > > --enable-stage1-checking --disable-multilib --enable-lto > > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > > --with-bugurl=https://trac.macports.org/newticket > > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > > Thread model: posix > > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ gfortran -v > > > > Using built-in specs. > > > > COLLECT_GCC=gfortran > > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > > Target: x86_64-apple-darwin11 > > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > > --build=x86_64-apple-darwin11 > > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > > --libdir=/opt/local/lib/gcc48 > > > > --includedir=/opt/local/include/gcc48 > > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > > --datarootdir=/opt/local/share/gcc-4.8 > > > > --with-local-prefix=/opt/local > > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > > --with-mpc=/opt/local > > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > > --enable-stage1-checking --disable-multilib --enable-lto > > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > > --with-bugurl=https://trac.macports.org/newticket > > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > > Thread model: posix > > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ uname -a > > > > Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version > > > > 11.4.2: > > > > Thu Aug 23 16:25:48 PDT 2012; > > > > root:xnu-1699.32.7~1/RELEASE_X86_64 > > > > x86_64 > > > > > > > > -- > > > > 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 > > > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > > > > > > > > > -- > > 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 > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > > > -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] hwloc build failing on Mac with GCC
by Ken Raffenetti 31 Jul '13

31 Jul '13

I'll just note that building on our OSX 10.7.4 test environment doesn't show any issues in this configuration. ----- Original Message ----- > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > To: devel(a)mpich.org > Sent: Wednesday, July 31, 2013 4:00:59 PM > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > Yes, that's right. Sorry. It's attached. > > Jeff > > ----- Original Message ----- > > From: "Ken Raffenetti" <raffenet(a)mcs.anl.gov> > > To: devel(a)mpich.org > > Sent: Wednesday, July 31, 2013 3:51:01 PM > > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > > > Maybe I'm missing something, but I fail to find a problem in the > > attachment. Did you mean to attach a make log? > > > > ----- Original Message ----- > > > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > > > To: "MPICH" <devel(a)mpich.org> > > > Sent: Wednesday, July 31, 2013 2:43:55 PM > > > Subject: [mpich-devel] hwloc build failing on Mac with GCC > > > > > > Am I stupid or is something broken? This is the git head as of a > > > few > > > minutes ago. > > > > > > Note that the essence of the problem is in the attachment. I > > > will > > > not > > > repeat it here. > > > > > > Thanks, > > > > > > Jeff > > > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ gcc -v > > > Using built-in specs. > > > COLLECT_GCC=gcc > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > Target: x86_64-apple-darwin11 > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > --build=x86_64-apple-darwin11 > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > --libdir=/opt/local/lib/gcc48 > > > --includedir=/opt/local/include/gcc48 > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > --datarootdir=/opt/local/share/gcc-4.8 > > > --with-local-prefix=/opt/local > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > --with-mpc=/opt/local > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > --enable-stage1-checking --disable-multilib --enable-lto > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > --with-bugurl=https://trac.macports.org/newticket > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > Thread model: posix > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > Jeffs-MacBook-Pro:build-gcc jhammond$ g++ -v > > > Using built-in specs. > > > COLLECT_GCC=g++ > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > Target: x86_64-apple-darwin11 > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > --build=x86_64-apple-darwin11 > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > --libdir=/opt/local/lib/gcc48 > > > --includedir=/opt/local/include/gcc48 > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > --datarootdir=/opt/local/share/gcc-4.8 > > > --with-local-prefix=/opt/local > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > --with-mpc=/opt/local > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > --enable-stage1-checking --disable-multilib --enable-lto > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > --with-bugurl=https://trac.macports.org/newticket > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > Thread model: posix > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > Jeffs-MacBook-Pro:build-gcc jhammond$ gfortran -v > > > Using built-in specs. > > > COLLECT_GCC=gfortran > > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > > Target: x86_64-apple-darwin11 > > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > > --build=x86_64-apple-darwin11 > > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > > --libdir=/opt/local/lib/gcc48 > > > --includedir=/opt/local/include/gcc48 > > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > > --datarootdir=/opt/local/share/gcc-4.8 > > > --with-local-prefix=/opt/local > > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > > --with-gmp=/opt/local --with-mpfr=/opt/local > > > --with-mpc=/opt/local > > > --with-ppl=/opt/local --with-cloog=/opt/local > > > --enable-cloog-backend=isl --disable-cloog-version-check > > > --enable-stage1-checking --disable-multilib --enable-lto > > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > > --with-bugurl=https://trac.macports.org/newticket > > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > > Thread model: posix > > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > > Jeffs-MacBook-Pro:build-gcc jhammond$ uname -a > > > Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version > > > 11.4.2: > > > Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 > > > x86_64 > > > > > > -- > > > 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 > > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > > > > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides > >

1 0

Re: [mpich-devel] hwloc build failing on Mac with GCC
by Jeff Hammond 31 Jul '13

31 Jul '13

Yes, that's right. Sorry. It's attached. Jeff ----- Original Message ----- > From: "Ken Raffenetti" <raffenet(a)mcs.anl.gov> > To: devel(a)mpich.org > Sent: Wednesday, July 31, 2013 3:51:01 PM > Subject: Re: [mpich-devel] hwloc build failing on Mac with GCC > > Maybe I'm missing something, but I fail to find a problem in the > attachment. Did you mean to attach a make log? > > ----- Original Message ----- > > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > > To: "MPICH" <devel(a)mpich.org> > > Sent: Wednesday, July 31, 2013 2:43:55 PM > > Subject: [mpich-devel] hwloc build failing on Mac with GCC > > > > Am I stupid or is something broken? This is the git head as of a > > few > > minutes ago. > > > > Note that the essence of the problem is in the attachment. I will > > not > > repeat it here. > > > > Thanks, > > > > Jeff > > > > Jeffs-MacBook-Pro:build-gcc jhammond$ gcc -v > > Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > Target: x86_64-apple-darwin11 > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > --build=x86_64-apple-darwin11 > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > --datarootdir=/opt/local/share/gcc-4.8 > > --with-local-prefix=/opt/local > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > > --with-ppl=/opt/local --with-cloog=/opt/local > > --enable-cloog-backend=isl --disable-cloog-version-check > > --enable-stage1-checking --disable-multilib --enable-lto > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > --with-bugurl=https://trac.macports.org/newticket > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > Thread model: posix > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > Jeffs-MacBook-Pro:build-gcc jhammond$ g++ -v > > Using built-in specs. > > COLLECT_GCC=g++ > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > Target: x86_64-apple-darwin11 > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > --build=x86_64-apple-darwin11 > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > --datarootdir=/opt/local/share/gcc-4.8 > > --with-local-prefix=/opt/local > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > > --with-ppl=/opt/local --with-cloog=/opt/local > > --enable-cloog-backend=isl --disable-cloog-version-check > > --enable-stage1-checking --disable-multilib --enable-lto > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > --with-bugurl=https://trac.macports.org/newticket > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > Thread model: posix > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > Jeffs-MacBook-Pro:build-gcc jhammond$ gfortran -v > > Using built-in specs. > > COLLECT_GCC=gfortran > > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > > Target: x86_64-apple-darwin11 > > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > > --build=x86_64-apple-darwin11 > > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > > --datarootdir=/opt/local/share/gcc-4.8 > > --with-local-prefix=/opt/local > > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > > --with-ppl=/opt/local --with-cloog=/opt/local > > --enable-cloog-backend=isl --disable-cloog-version-check > > --enable-stage1-checking --disable-multilib --enable-lto > > --enable-libstdcxx-time --with-as=/opt/local/bin/as > > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > > --with-bugurl=https://trac.macports.org/newticket > > --with-pkgversion='MacPorts gcc48 4.8.1_1' > > Thread model: posix > > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > > Jeffs-MacBook-Pro:build-gcc jhammond$ uname -a > > Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: > > Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 > > x86_64 > > > > -- > > 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 > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] hwloc build failing on Mac with GCC
by Ken Raffenetti 31 Jul '13

31 Jul '13

Maybe I'm missing something, but I fail to find a problem in the attachment. Did you mean to attach a make log? ----- Original Message ----- > From: "Jeff Hammond" <jhammond(a)alcf.anl.gov> > To: "MPICH" <devel(a)mpich.org> > Sent: Wednesday, July 31, 2013 2:43:55 PM > Subject: [mpich-devel] hwloc build failing on Mac with GCC > > Am I stupid or is something broken? This is the git head as of a few > minutes ago. > > Note that the essence of the problem is in the attachment. I will > not > repeat it here. > > Thanks, > > Jeff > > Jeffs-MacBook-Pro:build-gcc jhammond$ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > Target: x86_64-apple-darwin11 > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > --build=x86_64-apple-darwin11 > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > --with-ppl=/opt/local --with-cloog=/opt/local > --enable-cloog-backend=isl --disable-cloog-version-check > --enable-stage1-checking --disable-multilib --enable-lto > --enable-libstdcxx-time --with-as=/opt/local/bin/as > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > --with-bugurl=https://trac.macports.org/newticket > --with-pkgversion='MacPorts gcc48 4.8.1_1' > Thread model: posix > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > Jeffs-MacBook-Pro:build-gcc jhammond$ g++ -v > Using built-in specs. > COLLECT_GCC=g++ > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > Target: x86_64-apple-darwin11 > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > --build=x86_64-apple-darwin11 > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > --with-ppl=/opt/local --with-cloog=/opt/local > --enable-cloog-backend=isl --disable-cloog-version-check > --enable-stage1-checking --disable-multilib --enable-lto > --enable-libstdcxx-time --with-as=/opt/local/bin/as > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > --with-bugurl=https://trac.macports.org/newticket > --with-pkgversion='MacPorts gcc48 4.8.1_1' > Thread model: posix > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > Jeffs-MacBook-Pro:build-gcc jhammond$ gfortran -v > Using built-in specs. > COLLECT_GCC=gfortran > COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper > Target: x86_64-apple-darwin11 > Configured with: ../gcc-4.8.1/configure --prefix=/opt/local > --build=x86_64-apple-darwin11 > --enable-languages=c,c++,objc,obj-c++,lto,fortran,java > --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 > --infodir=/opt/local/share/info --mandir=/opt/local/share/man > --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local > --with-system-zlib --disable-nls --program-suffix=-mp-4.8 > --with-gxx-include-dir=/opt/local/include/gcc48/c++/ > --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local > --with-ppl=/opt/local --with-cloog=/opt/local > --enable-cloog-backend=isl --disable-cloog-version-check > --enable-stage1-checking --disable-multilib --enable-lto > --enable-libstdcxx-time --with-as=/opt/local/bin/as > --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar > --with-bugurl=https://trac.macports.org/newticket > --with-pkgversion='MacPorts gcc48 4.8.1_1' > Thread model: posix > gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) > Jeffs-MacBook-Pro:build-gcc jhammond$ uname -a > Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: > Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 > x86_64 > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides >

1 0

hwloc build failing on Mac with GCC
by Jeff Hammond 31 Jul '13

31 Jul '13

Am I stupid or is something broken? This is the git head as of a few minutes ago. Note that the essence of the problem is in the attachment. I will not repeat it here. Thanks, Jeff Jeffs-MacBook-Pro:build-gcc jhammond$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_1' Thread model: posix gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) Jeffs-MacBook-Pro:build-gcc jhammond$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_1' Thread model: posix gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) Jeffs-MacBook-Pro:build-gcc jhammond$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper Target: x86_64-apple-darwin11 Configured with: ../gcc-4.8.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8.1_1' Thread model: posix gcc version 4.8.1 (MacPorts gcc48 4.8.1_1) Jeffs-MacBook-Pro:build-gcc jhammond$ uname -a Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Collective i/o failure
by Rusty Lusk 25 Jul '13

25 Jul '13

Yes, the collchk library, which is an MPI profiling library tool, was done by a student, me, and Anthony a while back, and is still available as part of MPE. Its main contribution is to check consistency of input parameters for collective calls (e.g. everyone calls MPI_Bcast specifying same root). But the same approach could certainly be used to check consistency of return codes. Advantage: works with any MPI, does not touch the MPI implementation. Disadvantage: introduces overhead of a subroutine call, plus an extra collective. Easy to swap in and out. Rusty On Thursday,Jul 25, 2013, at 2:02 PM, Rob Ross wrote: > Hi, > > No, discussions of whether we should be checking that parameters are valid in a collective way, so that we can give a proper error back to all ranks in the case where one rank has a problem. > > It is not generally the case that collectives are free. This type of error checking has been done in add-on libraries, for example, to help in debugging. I think A. Chan et al. did an instance of this some time back. > > Rob > > On Jul 25, 2013, at 1:57 PM, Jeff Hammond wrote: > >> BG-specific discussions? I don't care what the Forum thinks about an implementation detail that makes BG more productive for our users. >> >> If MPIO_CHECK_OFFSET_ALL is optional and IBM chooses to enable it, what does that matter to anyone else? >> >> Jeff >> >> ----- Original Message ----- >>> From: "Rob Ross" <rross(a)mcs.anl.gov> >>> To: devel(a)mpich.org >>> Sent: Thursday, July 25, 2013 2:31:16 PM >>> Subject: Re: [mpich-devel] Collective i/o failure >>> >>> See historical discussions on collective argument checking. -- Rob >>> >>> On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote: >>> >>>> MPI_Allreduce on an integer should be almost infinitely fast on BG >>>> so maybe an ifdef guard is all that is required to keep this from >>>> standing in the way of widespread acceptance of MPI-IO. >>>> >>>> Best, >>>> >>>> Jeff >>>> >>>> ----- Original Message ----- >>>>> From: "Rob Ross" <rross(a)mcs.anl.gov> >>>>> To: devel(a)mpich.org >>>>> Sent: Thursday, July 25, 2013 2:03:40 PM >>>>> Subject: Re: [mpich-devel] Collective i/o failure >>>>> >>>>> Just to reiterate the point that RobL made: adding collectives to >>>>> check for completion, etc. of other ranks adds overhead to the >>>>> calls >>>>> when they are successful. This in turn makes people not use >>>>> MPI-IO, >>>>> because it becomes slower, which is good for reducing bug reports, >>>>> but bad for encouraging use of standard interfaces. >>>>> >>>>> Rob >>>>> >>>>> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote: >>>>> >>>>>>> From: "Rob Latham" <robl(a)mcs.anl.gov> >>>>>> >>>>>>> How did this single rank get a negative offset? Was there some >>>>>>> integer math that overflowed? >>>>>> >>>>>> That's for the app developer to figure out. My issue is that if >>>>>> all ranks had failed the write he probably would have started >>>>>> figuring that out a few days ago and I wouldn't have gotten >>>>>> involved :) It's the weird hw error that dragged me into this >>>>>> when the non-failing ranks entered allreduce in romio and the >>>>>> failing ranks entered allreduce in the app. >>>>>> >>>>>> Like I said : >>>>>> >>>>>>>> Just wondering if there's something I can fix here in addition >>>>>>>> to the >>>>>>>> application. >>>>>> >>>>>> Not the highest priority really. But I coincidentally just got >>>>>> another report (from ANL this time) that an app is hung with half >>>>>> the ranks in write_at_all and half the ranks in a later barrier. >>>>>> It could be something similar. I don't have enough information >>>>>> yet to know but I've suggested they look at errors from write. >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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 >>>> ALCF docs: http://www.alcf.anl.gov/user-guides >>>> >>> >>> >> >> -- >> 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 >> ALCF docs: http://www.alcf.anl.gov/user-guides >> >

1 0

Re: [mpich-devel] Collective i/o failure
by Rob Ross 25 Jul '13

25 Jul '13

Hi, No, discussions of whether we should be checking that parameters are valid in a collective way, so that we can give a proper error back to all ranks in the case where one rank has a problem. It is not generally the case that collectives are free. This type of error checking has been done in add-on libraries, for example, to help in debugging. I think A. Chan et al. did an instance of this some time back. Rob On Jul 25, 2013, at 1:57 PM, Jeff Hammond wrote: > BG-specific discussions? I don't care what the Forum thinks about an implementation detail that makes BG more productive for our users. > > If MPIO_CHECK_OFFSET_ALL is optional and IBM chooses to enable it, what does that matter to anyone else? > > Jeff > > ----- Original Message ----- >> From: "Rob Ross" <rross(a)mcs.anl.gov> >> To: devel(a)mpich.org >> Sent: Thursday, July 25, 2013 2:31:16 PM >> Subject: Re: [mpich-devel] Collective i/o failure >> >> See historical discussions on collective argument checking. -- Rob >> >> On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote: >> >>> MPI_Allreduce on an integer should be almost infinitely fast on BG >>> so maybe an ifdef guard is all that is required to keep this from >>> standing in the way of widespread acceptance of MPI-IO. >>> >>> Best, >>> >>> Jeff >>> >>> ----- Original Message ----- >>>> From: "Rob Ross" <rross(a)mcs.anl.gov> >>>> To: devel(a)mpich.org >>>> Sent: Thursday, July 25, 2013 2:03:40 PM >>>> Subject: Re: [mpich-devel] Collective i/o failure >>>> >>>> Just to reiterate the point that RobL made: adding collectives to >>>> check for completion, etc. of other ranks adds overhead to the >>>> calls >>>> when they are successful. This in turn makes people not use >>>> MPI-IO, >>>> because it becomes slower, which is good for reducing bug reports, >>>> but bad for encouraging use of standard interfaces. >>>> >>>> Rob >>>> >>>> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote: >>>> >>>>>> From: "Rob Latham" <robl(a)mcs.anl.gov> >>>>> >>>>>> How did this single rank get a negative offset? Was there some >>>>>> integer math that overflowed? >>>>> >>>>> That's for the app developer to figure out. My issue is that if >>>>> all ranks had failed the write he probably would have started >>>>> figuring that out a few days ago and I wouldn't have gotten >>>>> involved :) It's the weird hw error that dragged me into this >>>>> when the non-failing ranks entered allreduce in romio and the >>>>> failing ranks entered allreduce in the app. >>>>> >>>>> Like I said : >>>>> >>>>>>> Just wondering if there's something I can fix here in addition >>>>>>> to the >>>>>>> application. >>>>> >>>>> Not the highest priority really. But I coincidentally just got >>>>> another report (from ANL this time) that an app is hung with half >>>>> the ranks in write_at_all and half the ranks in a later barrier. >>>>> It could be something similar. I don't have enough information >>>>> yet to know but I've suggested they look at errors from write. >>>>> >>>> >>>> >>> >>> -- >>> 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 >>> ALCF docs: http://www.alcf.anl.gov/user-guides >>> >> >> > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides >

1 0

Re: [mpich-devel] Collective i/o failure
by Michael Blocksome 25 Jul '13

25 Jul '13

I'm actually a bit surprised that there isn't already a '--enable-collective-argument-checks' configure option that would default to "disabled". Michael Blocksome Blue Gene Messaging blocksom(a)us.ibm.com From: Jeff Hammond <jhammond(a)alcf.anl.gov> To: devel(a)mpich.org, Date: 07/25/2013 01:59 PM Subject: Re: [mpich-devel] Collective i/o failure Sent by: devel-bounces(a)mpich.org BG-specific discussions? I don't care what the Forum thinks about an implementation detail that makes BG more productive for our users. If MPIO_CHECK_OFFSET_ALL is optional and IBM chooses to enable it, what does that matter to anyone else? Jeff ----- Original Message ----- > From: "Rob Ross" <rross(a)mcs.anl.gov> > To: devel(a)mpich.org > Sent: Thursday, July 25, 2013 2:31:16 PM > Subject: Re: [mpich-devel] Collective i/o failure > > See historical discussions on collective argument checking. -- Rob > > On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote: > > > MPI_Allreduce on an integer should be almost infinitely fast on BG > > so maybe an ifdef guard is all that is required to keep this from > > standing in the way of widespread acceptance of MPI-IO. > > > > Best, > > > > Jeff > > > > ----- Original Message ----- > >> From: "Rob Ross" <rross(a)mcs.anl.gov> > >> To: devel(a)mpich.org > >> Sent: Thursday, July 25, 2013 2:03:40 PM > >> Subject: Re: [mpich-devel] Collective i/o failure > >> > >> Just to reiterate the point that RobL made: adding collectives to > >> check for completion, etc. of other ranks adds overhead to the > >> calls > >> when they are successful. This in turn makes people not use > >> MPI-IO, > >> because it becomes slower, which is good for reducing bug reports, > >> but bad for encouraging use of standard interfaces. > >> > >> Rob > >> > >> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote: > >> > >>>> From: "Rob Latham" <robl(a)mcs.anl.gov> > >>> > >>>> How did this single rank get a negative offset? Was there some > >>>> integer math that overflowed? > >>> > >>> That's for the app developer to figure out. My issue is that if > >>> all ranks had failed the write he probably would have started > >>> figuring that out a few days ago and I wouldn't have gotten > >>> involved :) It's the weird hw error that dragged me into this > >>> when the non-failing ranks entered allreduce in romio and the > >>> failing ranks entered allreduce in the app. > >>> > >>> Like I said : > >>> > >>>>> Just wondering if there's something I can fix here in addition > >>>>> to the > >>>>> application. > >>> > >>> Not the highest priority really. But I coincidentally just got > >>> another report (from ANL this time) that an app is hung with half > >>> the ranks in write_at_all and half the ranks in a later barrier. > >>> It could be something similar. I don't have enough information > >>> yet to know but I've suggested they look at errors from write. > >>> > >> > >> > > > > -- > > 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 > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > > -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Collective i/o failure
by Jeff Hammond 25 Jul '13

25 Jul '13

BG-specific discussions? I don't care what the Forum thinks about an implementation detail that makes BG more productive for our users. If MPIO_CHECK_OFFSET_ALL is optional and IBM chooses to enable it, what does that matter to anyone else? Jeff ----- Original Message ----- > From: "Rob Ross" <rross(a)mcs.anl.gov> > To: devel(a)mpich.org > Sent: Thursday, July 25, 2013 2:31:16 PM > Subject: Re: [mpich-devel] Collective i/o failure > > See historical discussions on collective argument checking. -- Rob > > On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote: > > > MPI_Allreduce on an integer should be almost infinitely fast on BG > > so maybe an ifdef guard is all that is required to keep this from > > standing in the way of widespread acceptance of MPI-IO. > > > > Best, > > > > Jeff > > > > ----- Original Message ----- > >> From: "Rob Ross" <rross(a)mcs.anl.gov> > >> To: devel(a)mpich.org > >> Sent: Thursday, July 25, 2013 2:03:40 PM > >> Subject: Re: [mpich-devel] Collective i/o failure > >> > >> Just to reiterate the point that RobL made: adding collectives to > >> check for completion, etc. of other ranks adds overhead to the > >> calls > >> when they are successful. This in turn makes people not use > >> MPI-IO, > >> because it becomes slower, which is good for reducing bug reports, > >> but bad for encouraging use of standard interfaces. > >> > >> Rob > >> > >> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote: > >> > >>>> From: "Rob Latham" <robl(a)mcs.anl.gov> > >>> > >>>> How did this single rank get a negative offset? Was there some > >>>> integer math that overflowed? > >>> > >>> That's for the app developer to figure out. My issue is that if > >>> all ranks had failed the write he probably would have started > >>> figuring that out a few days ago and I wouldn't have gotten > >>> involved :) It's the weird hw error that dragged me into this > >>> when the non-failing ranks entered allreduce in romio and the > >>> failing ranks entered allreduce in the app. > >>> > >>> Like I said : > >>> > >>>>> Just wondering if there's something I can fix here in addition > >>>>> to the > >>>>> application. > >>> > >>> Not the highest priority really. But I coincidentally just got > >>> another report (from ANL this time) that an app is hung with half > >>> the ranks in write_at_all and half the ranks in a later barrier. > >>> It could be something similar. I don't have enough information > >>> yet to know but I've suggested they look at errors from write. > >>> > >> > >> > > > > -- > > 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 > > ALCF docs: http://www.alcf.anl.gov/user-guides > > > > -- 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 ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

Re: [mpich-devel] Collective i/o failure
by Rob Ross 25 Jul '13

25 Jul '13

See historical discussions on collective argument checking. -- Rob On Jul 25, 2013, at 1:13 PM, Jeff Hammond wrote: > MPI_Allreduce on an integer should be almost infinitely fast on BG so maybe an ifdef guard is all that is required to keep this from standing in the way of widespread acceptance of MPI-IO. > > Best, > > Jeff > > ----- Original Message ----- >> From: "Rob Ross" <rross(a)mcs.anl.gov> >> To: devel(a)mpich.org >> Sent: Thursday, July 25, 2013 2:03:40 PM >> Subject: Re: [mpich-devel] Collective i/o failure >> >> Just to reiterate the point that RobL made: adding collectives to >> check for completion, etc. of other ranks adds overhead to the calls >> when they are successful. This in turn makes people not use MPI-IO, >> because it becomes slower, which is good for reducing bug reports, >> but bad for encouraging use of standard interfaces. >> >> Rob >> >> On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote: >> >>>> From: "Rob Latham" <robl(a)mcs.anl.gov> >>> >>>> How did this single rank get a negative offset? Was there some >>>> integer math that overflowed? >>> >>> That's for the app developer to figure out. My issue is that if >>> all ranks had failed the write he probably would have started >>> figuring that out a few days ago and I wouldn't have gotten >>> involved :) It's the weird hw error that dragged me into this >>> when the non-failing ranks entered allreduce in romio and the >>> failing ranks entered allreduce in the app. >>> >>> Like I said : >>> >>>>> Just wondering if there's something I can fix here in addition >>>>> to the >>>>> application. >>> >>> Not the highest priority really. But I coincidentally just got >>> another report (from ANL this time) that an app is hung with half >>> the ranks in write_at_all and half the ranks in a later barrier. >>> It could be something similar. I don't have enough information >>> yet to know but I've suggested they look at errors from write. >>> >> >> > > -- > 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 > ALCF docs: http://www.alcf.anl.gov/user-guides >

1 0