October 2018 - discuss - mailman3.cels.anl.gov

Assertion failed in file ch3i_comm.c
by Chao-Chin Yang 06 Oct '18

06 Oct '18

Hi, I am using mpicxx for MPICH version 3.2.1 Apple LLVM version 10.0.0 (clang-1000.11.45.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin But I run into a runtime error: Assertion failed in file src/mpid/ch3/channels/nemesis/src/ch3i_comm.c at line 139: 0 internal ABORT - process 0 Assertion failed in file src/mpid/ch3/channels/nemesis/src/ch3i_comm.c at line 139: 0 internal ABORT - process 1 I looked into the source code ch3i_comm.c and found that there is a FIXME comment but I am not quite sure I get the picture. So my question is: In what condition(s) does one get this assertion error? Sincerely, Chao-Chin Yang Postdoctoral Scholar Department of Physics and Astronomy University of Nevada, Las Vegas, U.S.A. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] mpich-master: undefined references using Sun C
by Madhu, Kavitha Tiptur 05 Oct '18

05 Oct '18

Hi I have created an issue here: https://github.com/pmodels/mpich/issues/3358 [https://avatars0.githubusercontent.com/u/1934591?s=400&v=4]<https://github.com/pmodels/mpich/issues/3358> Linker error building mpich master mpich-master on "SUSE Linux Enterprise Server 12.3 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6). · Issue #3358 · pmodels/mpich<https://github.com/pmodels/mpich/issues/3358> github.com Linker error reported by Siegmar Gross siegmar.gross(a)informatik.hs-fulda.de when building MPICH master. loki mpich-master_2018-10-05_Linux.x86_64.64_cc 128 head -7 config.log | tail -1 $ ../mpich/c... I would update the issue once reproduce the error and gain some insight into the problem. ________________________________ From: Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de> Sent: Friday, October 5, 2018 4:24:49 AM To: Users MPICH Subject: [mpich-discuss] mpich-master: undefined references using Sun C Hi, I tried to install mpich-master on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6). Unfortunately, I get the following error. loki mpich-master_2018-10-05_Linux.x86_64.64_cc 128 head -7 config.log | tail -1 $ ../mpich/configure --prefix=/usr/local/mpich-master_64_cc --libdir=/usr/local/mpich-master_64_cc/lib64 --includedir=/usr/local/mpich-master_64_cc/include64 CC=cc CXX=CC F77=f77 FC=f95 CFLAGS=-m64 CXXFLAGS=-m64 FFLAGS=-m64 FCFLAGS=-m64 LDFLAGS=-m64 -L/usr/lib64 -R/usr/lib64 --enable-fortran=no --enable-cxx --enable-romio --enable-debuginfo --enable-smpcoll --enable-threads=multiple --with-thread-package=posix --enable-shared loki mpich-master_2018-10-05_Linux.x86_64.64_cc 128 tail -40 log.make.Linux.x86_64.64_cc "/export2/src/mpich-master/mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 162: warning: parameter in inline asm statement unused: %3 "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect CC src/env/mpivars.o CCLD lib/libtvmpich.la GEN lib/libmpi.la "./src/include/mpichconf.h", line 1718: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. 1 Warning(s) detected. CXXLD lib/libmpicxx.la CCLD src/env/mpichversion CCLD src/env/mpivars CC: -library=Crun cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 CC: -library=Cstd cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 Makefile:10783: recipe for target 'lib/libmpicxx.la' failed make[2]: *** [lib/libmpicxx.la] Error 1 make[2]: *** Waiting for unfinished jobs.... src/env/mpichversion.o: In function `hwloc_distrib': mpichversion.c:(.text+0xb0): undefined reference to `hwloc_bitmap_weight' mpichversion.c:(.text+0x13d): undefined reference to `hwloc_bitmap_weight' mpichversion.c:(.text+0x1e4): undefined reference to `hwloc_bitmap_dup' mpichversion.c:(.text+0x219): undefined reference to `hwloc_bitmap_or' src/env/mpichversion.o: In function `MPIR_Datatype_free_contents': mpichversion.c:(.text+0x30d): undefined reference to `MPIR_Datatype_builtin' mpichversion.c:(.text+0x32b): undefined reference to `MPIR_Datatype_direct' mpichversion.c:(.text+0x339): undefined reference to `MPIR_Datatype_mem' mpichversion.c:(.text+0x37f): undefined reference to `MPIR_Process' mpichversion.c:(.text+0x3f9): undefined reference to `MPIR_Assert_fail' src/env/mpichversion.o: In function `MPIR_Datatype_free': mpichversion.c:(.text+0x43e): undefined reference to `MPIR_Dataloop_free' mpichversion.c:(.text+0x445): undefined reference to `MPIR_Datatype_mem' postopt: error: ld failed to link the binary cc: postopt failed for src/env/.libs/mpichversion Makefile:20510: recipe for target 'src/env/mpichversion' failed make[2]: *** [src/env/mpichversion] Error 2 make[2]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-10-05_Linux.x86_64.64_cc' Makefile:40490: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-10-05_Linux.x86_64.64_cc' Makefile:10578: recipe for target 'all' failed make: *** [all] Error 2 loki mpich-master_2018-10-05_Linux.x86_64.64_cc 129 I would be grateful, if somebody can fix the problem. Do you need anything else? Thank you very much for any help in advance. Kind regards Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss discuss Info Page - MPICH<https://lists.mpich.org/mailman/listinfo/discuss> lists.mpich.org To see the collection of prior postings to the list, visit the discuss Archives.. Using discuss: To post a message to all the list members, send email to discuss(a)mpich.org. You can subscribe to the list, or change your existing subscription, in the sections below. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich-master: undefined references using Sun C
by Siegmar Gross 05 Oct '18

05 Oct '18

Hi, I tried to install mpich-master on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6). Unfortunately, I get the following error. loki mpich-master_2018-10-05_Linux.x86_64.64_cc 128 head -7 config.log | tail -1 $ ../mpich/configure --prefix=/usr/local/mpich-master_64_cc --libdir=/usr/local/mpich-master_64_cc/lib64 --includedir=/usr/local/mpich-master_64_cc/include64 CC=cc CXX=CC F77=f77 FC=f95 CFLAGS=-m64 CXXFLAGS=-m64 FFLAGS=-m64 FCFLAGS=-m64 LDFLAGS=-m64 -L/usr/lib64 -R/usr/lib64 --enable-fortran=no --enable-cxx --enable-romio --enable-debuginfo --enable-smpcoll --enable-threads=multiple --with-thread-package=posix --enable-shared loki mpich-master_2018-10-05_Linux.x86_64.64_cc 128 tail -40 log.make.Linux.x86_64.64_cc "/export2/src/mpich-master/mpich/src/openpa/src/primitives/opa_gcc_intel_32_64_ops.h", line 162: warning: parameter in inline asm statement unused: %3 "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect CC src/env/mpivars.o CCLD lib/libtvmpich.la GEN lib/libmpi.la "./src/include/mpichconf.h", line 1718: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. 1 Warning(s) detected. CXXLD lib/libmpicxx.la CCLD src/env/mpichversion CCLD src/env/mpivars CC: -library=Crun cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 CC: -library=Cstd cannot be used with -std=c++03. To use this library you need to switch to -std=sun03 Makefile:10783: recipe for target 'lib/libmpicxx.la' failed make[2]: *** [lib/libmpicxx.la] Error 1 make[2]: *** Waiting for unfinished jobs.... src/env/mpichversion.o: In function `hwloc_distrib': mpichversion.c:(.text+0xb0): undefined reference to `hwloc_bitmap_weight' mpichversion.c:(.text+0x13d): undefined reference to `hwloc_bitmap_weight' mpichversion.c:(.text+0x1e4): undefined reference to `hwloc_bitmap_dup' mpichversion.c:(.text+0x219): undefined reference to `hwloc_bitmap_or' src/env/mpichversion.o: In function `MPIR_Datatype_free_contents': mpichversion.c:(.text+0x30d): undefined reference to `MPIR_Datatype_builtin' mpichversion.c:(.text+0x32b): undefined reference to `MPIR_Datatype_direct' mpichversion.c:(.text+0x339): undefined reference to `MPIR_Datatype_mem' mpichversion.c:(.text+0x37f): undefined reference to `MPIR_Process' mpichversion.c:(.text+0x3f9): undefined reference to `MPIR_Assert_fail' src/env/mpichversion.o: In function `MPIR_Datatype_free': mpichversion.c:(.text+0x43e): undefined reference to `MPIR_Dataloop_free' mpichversion.c:(.text+0x445): undefined reference to `MPIR_Datatype_mem' postopt: error: ld failed to link the binary cc: postopt failed for src/env/.libs/mpichversion Makefile:20510: recipe for target 'src/env/mpichversion' failed make[2]: *** [src/env/mpichversion] Error 2 make[2]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-10-05_Linux.x86_64.64_cc' Makefile:40490: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-10-05_Linux.x86_64.64_cc' Makefile:10578: recipe for target 'all' failed make: *** [all] Error 2 loki mpich-master_2018-10-05_Linux.x86_64.64_cc 129 I would be grateful, if somebody can fix the problem. Do you need anything else? Thank you very much for any help in advance. Kind regards Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] couldn't built mpich-master on SuSE Linux with Sun C
by Congiu, Giuseppe 03 Oct '18

03 Oct '18

Siegmar, I have created a pull request that should fix the fortran detection problem with mpich. Can you try it and see if it works for you? Thank you, Giuseppe On Oct 3, 2018, at 1:25 PM, Congiu, Giuseppe <gcongiu(a)anl.gov<mailto:[email protected]>> wrote: Hi Siegmar, We have looked into the problem. It seems this is not MPICH specific but rather libtools specific. I have created an issue (https://github.com/pmodels/mpich/issues/3350) for this. You can look at it for bug fix updates. Best, Giuseppe On Oct 1, 2018, at 6:16 AM, Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de<mailto:[email protected]>> wrote: Hi Giuseppe, my email is being held until the list moderator can review it for approval, because the attachments are too big. Therefore, I send it directly to you. Best regards Siegmar -------- Forwarded Message -------- Subject: Re: [mpich-discuss] couldn't built mpich-master on SuSE Linux with Sun C Date: Mon, 1 Oct 2018 10:37:58 +0200 From: Siegmar Gross <Siegmar.Gross(a)informatik.hs-fulda.de<mailto:[email protected]>> To: Users MPICH <discuss(a)mpich.org<mailto:[email protected]>> Hi Giuseppe, today I've tried to build the latest master version so that you don't have to deal with an old version. I still get the same error. loki mpich-master_2018-10-01_Linux.x86_64.64_cc 150 cc -V cc: Studio 12.6 Sun C 5.15 Linux_i386 2017/05/30 I've attached the requested files. Thank you very much for any help in advance. Best regards Siegmar On 09/26/18 21:41, Congiu, Giuseppe wrote: Hi Siegmar, I have tried replicating the linking problem using the configure options you provided. I have used Oracle Developer Studio 12.3. Mpich master “701bc7e5f84467188dcdc1ff585349e994a9990a". Compilation worked fine for me. Can you attach your config.log file so I can have a look at it? Moreover, can you recompile Mpich with "make V=1" and attach the corresponding output as well? Thank you, Giuseppe On Jun 6, 2018, at 6:21 AM, Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de<mailto:[email protected]>> wrote: Hi, I tried to build mpich-master on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6). Unfortunately, I get the following error, that I already reported already on May 9th. loki mpich-master_2018-06-06_Linux.x86_64.64_cc 122 tail -22 log.make.Linux.x86_64.64_cc | grep -v NOTICE "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect MOD src/binding/fortran/use_mpi/mpi.mod-stamp "./src/include/mpichconf.h", line 1708: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. 1 Warning(s) detected. f90: Warning: Option -shared passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option --whole-archive passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option --no-whole-archive passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -path passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -path passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -soname passed to ld, if ld is invoked, ignored otherwise /usr/bin/ld: -r and -shared may not be used together postopt: error: ld failed to link the binary Makefile:16787: recipe for target 'lib/libmpi.la<http://libmpi.la/>' failed make[2]: *** [lib/libmpi.la<http://libmpi.la/>] Error 2 make[2]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-06-06_Linux.x86_64.64_cc' Makefile:39797: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-06-06_Linux.x86_64.64_cc' Makefile:10453: recipe for target 'all' failed make: *** [all] Error 2 loki mpich-master_2018-06-06_Linux.x86_64.64_cc 123 I used the following commands to update and configure MPICH. cd mpich git pull https://github.com/pmodels/mpich.git master git submodule update --init --recursive autogen.sh mkdir mpich-master_`date -I'date'`_${SYSTEM_ENV}.${MACHINE_ENV}.64_cc cd mpich-master_`date -I'date'`_${SYSTEM_ENV}.${MACHINE_ENV}.64_cc ../mpich/configure \ --prefix=/usr/local/mpich-master_64_cc \ --libdir=/usr/local/mpich-master_64_cc/lib64 \ --includedir=/usr/local/mpich-master_64_cc/include64 \ CC="cc" CXX="CC" F77="f77" FC="f95" \ CFLAGS="-m64" CXXFLAGS="-m64" FFLAGS="-m64" FCFLAGS="-m64" \ LDFLAGS="-m64 -L/usr/lib64 -R/usr/lib64" \ --enable-fortran=yes --enable-cxx --enable-romio \ --enable-debuginfo --enable-smpcoll \ --enable-threads=multiple --with-thread-package=posix \ --enable-shared \ |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_cc make -j 6 |& tee log.make.$SYSTEM_ENV.$MACHINE_ENV.64_cc I would be grateful, if somebody can fix the problem or is it a problem of the Oracle compiler?. Do you need anything else? Thank you very much for any help in advance. Kind regards Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss <config.log><log.configure.Linux.x86_64.64_cc><log.make.Linux.x86_64.64_cc> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] couldn't built mpich-master on SuSE Linux with Sun C
by Congiu, Giuseppe 03 Oct '18

03 Oct '18

Hi Siegmar, We have looked into the problem. It seems this is not MPICH specific but rather libtools specific. I have created an issue (https://github.com/pmodels/mpich/issues/3350) for this. You can look at it for bug fix updates. Best, Giuseppe On Oct 1, 2018, at 6:16 AM, Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de<mailto:[email protected]>> wrote: Hi Giuseppe, my email is being held until the list moderator can review it for approval, because the attachments are too big. Therefore, I send it directly to you. Best regards Siegmar -------- Forwarded Message -------- Subject: Re: [mpich-discuss] couldn't built mpich-master on SuSE Linux with Sun C Date: Mon, 1 Oct 2018 10:37:58 +0200 From: Siegmar Gross <Siegmar.Gross(a)informatik.hs-fulda.de<mailto:[email protected]>> To: Users MPICH <discuss(a)mpich.org<mailto:[email protected]>> Hi Giuseppe, today I've tried to build the latest master version so that you don't have to deal with an old version. I still get the same error. loki mpich-master_2018-10-01_Linux.x86_64.64_cc 150 cc -V cc: Studio 12.6 Sun C 5.15 Linux_i386 2017/05/30 I've attached the requested files. Thank you very much for any help in advance. Best regards Siegmar On 09/26/18 21:41, Congiu, Giuseppe wrote: Hi Siegmar, I have tried replicating the linking problem using the configure options you provided. I have used Oracle Developer Studio 12.3. Mpich master “701bc7e5f84467188dcdc1ff585349e994a9990a". Compilation worked fine for me. Can you attach your config.log file so I can have a look at it? Moreover, can you recompile Mpich with "make V=1" and attach the corresponding output as well? Thank you, Giuseppe On Jun 6, 2018, at 6:21 AM, Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de<mailto:[email protected]>> wrote: Hi, I tried to build mpich-master on my "SUSE Linux Enterprise Server 12.3 (x86_64)" with Sun C 5.15 (Oracle Developer Studio 12.6). Unfortunately, I get the following error, that I already reported already on May 9th. loki mpich-master_2018-06-06_Linux.x86_64.64_cc 122 tail -22 log.make.Linux.x86_64.64_cc | grep -v NOTICE "../mpich/src/include/mpir_handlemem.h", line 61: warning: null dimension: indirect "../mpich/src/include/mpir_handlemem.h", line 122: warning: null dimension: indirect MOD src/binding/fortran/use_mpi/mpi.mod-stamp "./src/include/mpichconf.h", line 1708: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. 1 Warning(s) detected. f90: Warning: Option -shared passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option --whole-archive passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option --no-whole-archive passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -path passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -path passed to ld, if ld is invoked, ignored otherwise f90: Warning: Option -soname passed to ld, if ld is invoked, ignored otherwise /usr/bin/ld: -r and -shared may not be used together postopt: error: ld failed to link the binary Makefile:16787: recipe for target 'lib/libmpi.la<http://libmpi.la>' failed make[2]: *** [lib/libmpi.la<http://libmpi.la>] Error 2 make[2]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-06-06_Linux.x86_64.64_cc' Makefile:39797: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/export2/src/mpich-master/mpich-master_2018-06-06_Linux.x86_64.64_cc' Makefile:10453: recipe for target 'all' failed make: *** [all] Error 2 loki mpich-master_2018-06-06_Linux.x86_64.64_cc 123 I used the following commands to update and configure MPICH. cd mpich git pull https://github.com/pmodels/mpich.git master git submodule update --init --recursive autogen.sh mkdir mpich-master_`date -I'date'`_${SYSTEM_ENV}.${MACHINE_ENV}.64_cc cd mpich-master_`date -I'date'`_${SYSTEM_ENV}.${MACHINE_ENV}.64_cc ../mpich/configure \ --prefix=/usr/local/mpich-master_64_cc \ --libdir=/usr/local/mpich-master_64_cc/lib64 \ --includedir=/usr/local/mpich-master_64_cc/include64 \ CC="cc" CXX="CC" F77="f77" FC="f95" \ CFLAGS="-m64" CXXFLAGS="-m64" FFLAGS="-m64" FCFLAGS="-m64" \ LDFLAGS="-m64 -L/usr/lib64 -R/usr/lib64" \ --enable-fortran=yes --enable-cxx --enable-romio \ --enable-debuginfo --enable-smpcoll \ --enable-threads=multiple --with-thread-package=posix \ --enable-shared \ |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_cc make -j 6 |& tee log.make.$SYSTEM_ENV.$MACHINE_ENV.64_cc I would be grateful, if somebody can fix the problem or is it a problem of the Oracle compiler?. Do you need anything else? Thank you very much for any help in advance. Kind regards Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss <config.log><log.configure.Linux.x86_64.64_cc><log.make.Linux.x86_64.64_cc> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [petsc-dev] Is mpich/master:a8a2b30fd21 tested with Petsc?
by Eric Chamberland 02 Oct '18

02 Oct '18

Hi, mainly for PETSc users: please do no waste your time using MPI released with Intel Parallel Studio 2019 since it is the buggy MPICH 3.3b2 for which this initial thread has been created... I just wrote a remind about this also on Intel forum: https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/t… Eric On 19/04/18 09:01 AM, Eric Chamberland wrote: > Hi, > > this morning, mpich/master with PETSc is 100% working again for us. > > Thanks to both commits: > > https://github.com/pmodels/mpich/commit/c597c8d79deea220a42751fda0f01ce7076… > > > https://github.com/pmodels/mpich/commit/8edabc7373b82dd660019e53d2461317658… > > > and thanks to everybody who helped: > > Satish > Min > Wesley > Ken > Rob > Jed > > :) > > Eric > > On 17/04/18 04:58 PM, Min Si wrote: >> Hi all, >> >> Thanks for narrowing down the problem. I checked the MPICH code and >> believe this is a bug in MPICH. I just created a PR to fix it: >> https://github.com/pmodels/mpich/pull/3097 >> >> It should be merged into MPICH master branch soon. >> >> Thanks, >> Min >> >> On 2018/04/17 14:10, Eric Chamberland wrote: >>> Hi, >>> >>> are we talking about the "tag" passed to MPI_Isend for example? >>> >>> but does that mean there is something to change for any MPI call >>> which involves tags usage or is it only a PETSc "bad" tag usage? >>> >>> thanks Satish for your finding! >>> >>> Eric >>> >>> On 16/04/18 11:31 PM, Satish Balay wrote: >>>> On Tue, 13 Mar 2018, Eric Chamberland wrote: >>>> >>>>> Hi, >>>>> >>>>> each night we are testing mpich/master with our petsc-based code. >>>>> I don't >>>>> know if PETSc team is doing the same thing with mpich/master? >>>>> (Maybe it is a >>>>> good idea?) >>>>> >>>>> Everything was fine (except the issue >>>>> https://github.com/pmodels/mpich/issues/2892) up to commit >>>>> 7b8d64debd, but >>>>> since commit mpich:a8a2b30fd21), I have a segfault on a any >>>>> parallel nightly >>>>> test. >>>> >>>> I attempted a bisect of the above range of commits - and narrowed >>>> down to: >>>> >>>>>>>>>>> >>>> db11d4c4a70e39a28be88ed32f00542301699e08 is the first bad commit >>>> <<<<<<< >>>>>>>>>>>> >>>> balay@asterix /home/balay/soft/build/mpich ((db11d4c4a...)|BISECTING) >>>> $ git show db11d4c4a70e39a28be88ed32f00542301699e08 >>>> commit db11d4c4a70e39a28be88ed32f00542301699e08 (HEAD, refs/bisect/bad) >>>> Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> >>>> Date: Thu Feb 15 11:37:59 2018 -0600 >>>> >>>> init: Fix tag upper limit initialization >>>> The starting point for this value is equivalent to the >>>> usable tag bits >>>> macro. This value should be set before device initialization, >>>> otherwise devices will assume they have more bits than are >>>> actually >>>> available. >>>> Signed-off-by: Wesley Bland <wesley.bland(a)intel.com> >>>> >>>> diff --git a/src/mpi/init/initthread.c b/src/mpi/init/initthread.c >>>> index cbc41f4d5..b31ae2f07 100644 >>>> --- a/src/mpi/init/initthread.c >>>> +++ b/src/mpi/init/initthread.c >>>> @@ -403,7 +403,7 @@ int MPIR_Init_thread(int *argc, char ***argv, >>>> int required, int *provided) >>>> MPIR_Process.attrs.host = MPI_PROC_NULL; >>>> MPIR_Process.attrs.io = MPI_PROC_NULL; >>>> MPIR_Process.attrs.lastusedcode = MPI_ERR_LASTCODE; >>>> - MPIR_Process.attrs.tag_ub = 0; >>>> + MPIR_Process.attrs.tag_ub = MPIR_TAG_USABLE_BITS; >>>> MPIR_Process.attrs.universe = MPIR_UNIVERSE_SIZE_NOT_SET; >>>> MPIR_Process.attrs.wtime_is_global = 0; >>>> @@ -531,13 +531,6 @@ int MPIR_Init_thread(int *argc, char ***argv, >>>> int required, int *provided) >>>> MPIR_Assert(((unsigned) MPIR_Process. >>>> attrs.tag_ub & ((unsigned) >>>> MPIR_Process.attrs.tag_ub + 1)) == 0); >>>> - /* Set aside tag space for tagged collectives and failure >>>> notification */ >>>> -#ifdef HAVE_TAG_ERROR_BITS >>>> - MPIR_Process.attrs.tag_ub >>= 3; >>>> -#else >>>> - MPIR_Process.attrs.tag_ub >>= 1; >>>> -#endif >>>> - >>>> /* Assert: tag_ub is at least the minimum asked for in the MPI >>>> spec */ >>>> MPIR_Assert(MPIR_Process.attrs.tag_ub >= 32767); >>>> <<<<<<<<<<<<<<<<< >>>> >>>> Reverthing this patch gets mpich-3.3b2 working with petsc >>>> >>>> Satish >>>> _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] lib/libmpi.so doesn't contain the MPI_Status_c2f symbol in the FreeBSD mpich package
by Si, Min 01 Oct '18

01 Oct '18

Hi Yuri, I figured out this problem. On FreeBSD, the MPI_* weak symbols must use __attribute__ ((weak, alias("PMPI_*"))), but such option is not set in some MPI functions such as MPI_Status_c2f. We will fix this problem in MPICH soon. You can use this ticket to check fixing status: https://github.com/pmodels/mpich/issues/3348 Thanks for reporting this bug. Min On 2018/09/29 0:50, Yuri wrote: > On 9/28/18 12:29 PM, Si, Min wrote: >> >> I need to build MPICH on the same FreeBSD version to figure it out. > > > Install into a VM using this ISO image: > https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/11.2/FreeB… > > In VM, cd /usr/ports/net/mpich && make > > > Yuri > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [Openmp-dev] Libomptarget fatal error 1: failure of target construct while offloading is mandatory
by Siegmar Gross 01 Oct '18

01 Oct '18

Hi George, > The problem was related to parallel reduction. Jonas Hahnfeld > submitted a patch (thanks Jonas). Your code must now work. Jonas, thank you very much for your patch. > Please update your copy of libomptarget > and recompile it. Let us know if there are any further issues. It seems to work now. Do you know, why I get more or less the same execution time for CPU and GPU? I would have expected a smaller value for the GPU. loki introduction 143 clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda dot_prod_accelerator_OpenMP.c loki introduction 144 /usr/bin/time -p a.out Number of processors: 24 Number of devices: 1 Default device: 0 Is initial device: 1 sum = 6.000000e+08 real 3.93 user 0.66 sys 2.64 loki introduction 145 clang -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu dot_prod_accelerator_OpenMP.c loki introduction 146 /usr/bin/time -p a.out Number of processors: 24 Number of devices: 4 Default device: 0 Is initial device: 1 sum = 6.000000e+08 real 3.51 user 10.35 sys 6.04 loki introduction 147 Best regards and thank you very much for all help once more Siegmar > > George > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > *From:* Siegmar Gross <siegmar.gross(a)informatik.hs-fulda.de> > *Sent:* 01 October 2018 15:59 > *To:* George Rokos; llvm-openmp-dev > *Subject:* Re: [Openmp-dev] Libomptarget fatal error 1: failure of target construct while offloading is mandatory > Hi George, > > thank you very much for your suggestions. > >> Apparently your application fails to offload to the GPU. And because offloading >> is mandatory (that's the default behavior) the library terminates the application. >> >> Can you compile libomptarget in debug mode and run the app with >> LIBOMPTARGET_DEBUG=1 to see the debug output? That will help us identify the >> problem. > > > > loki introduction 115 clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda > dot_prod_accelerator_OpenMP.c > loki introduction 116 a.out > Number of processors: 24 > Number of devices: 1 > Default device: 0 > Is initial device: 1 > Libomptarget fatal error 1: failure of target construct while offloading is > mandatory > > > loki introduction 117 setenv LIBOMPTARGET_DEBUG 1 > loki introduction 118 a.out > Libomptarget --> Loading RTLs... > Libomptarget --> Loading library 'libomptarget.rtl.ppc64.so'... > Libomptarget --> Unable to load library 'libomptarget.rtl.ppc64.so': > libomptarget.rtl.ppc64.so: cannot open shared object file: No such file or > directory! > Libomptarget --> Loading library 'libomptarget.rtl.x86_64.so'... > Libomptarget --> Successfully loaded library 'libomptarget.rtl.x86_64.so'! > Libomptarget --> Registering RTL libomptarget.rtl.x86_64.so supporting 4 devices! > Libomptarget --> Loading library 'libomptarget.rtl.cuda.so'... > Target CUDA RTL --> Start initializing CUDA > Libomptarget --> Successfully loaded library 'libomptarget.rtl.cuda.so'! > Libomptarget --> Registering RTL libomptarget.rtl.cuda.so supporting 1 devices! > Libomptarget --> Loading library 'libomptarget.rtl.aarch64.so'... > Libomptarget --> Unable to load library 'libomptarget.rtl.aarch64.so': > libomptarget.rtl.aarch64.so: cannot open shared object file: No such file or > directory! > Libomptarget --> RTLs loaded! > Libomptarget --> Image 0x0000000000602090 is NOT compatible with RTL > libomptarget.rtl.x86_64.so! > Libomptarget --> Image 0x0000000000602090 is compatible with RTL > libomptarget.rtl.cuda.so! > Libomptarget --> RTL 0x00000000609f95d0 has index 0! > Libomptarget --> Registering image 0x0000000000602090 with RTL > libomptarget.rtl.cuda.so! > Libomptarget --> Done registering entries! > Libomptarget --> Call to omp_get_num_devices returning 1 > Libomptarget --> Default TARGET OFFLOAD policy is now mandatory (devicew were found) > Libomptarget --> Entering target region with entry point 0x00000000004012d0 and > device Id -1 > Libomptarget --> Checking whether device 0 is ready. > Libomptarget --> Is the device 0 (local ID 0) initialized? 0 > Target CUDA RTL --> Getting device 0 > Target CUDA RTL --> Max CUDA blocks per grid 2147483647 exceeds the hard team > limit 65536, capping at the hard limit > Target CUDA RTL --> Using 1024 CUDA threads per block > Target CUDA RTL --> Max number of CUDA blocks 65536, threads 1024 & warp size 32 > Target CUDA RTL --> Default number of teams set according to library's default 128 > Target CUDA RTL --> Default number of threads set according to library's default 128 > Libomptarget --> Device 0 is ready to use. > Target CUDA RTL --> Load data from image 0x0000000000602090 > Target CUDA RTL --> CUDA module successfully loaded! > Target CUDA RTL --> Entry point 0x0000000000000000 maps to > __omp_offloading_2b_1890d30_main_l48 (0x0000000060f23320) > Target CUDA RTL --> Entry point 0x0000000000000001 maps to > __omp_offloading_2b_1890d30_main_l67 (0x0000000060f27c70) > Target CUDA RTL --> Sending global device environment data 4 bytes > Libomptarget --> Entry 0: Base=0x0000000000613bf0, Begin=0x0000000000613bf0, > Size=800000000, Type=0x22 > Libomptarget --> Entry 1: Base=0x00000000301043f0, Begin=0x00000000301043f0, > Size=800000000, Type=0x22 > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Creating new map entry: HstBase=0x0000000000613bf0, > HstBegin=0x0000000000613bf0, HstEnd=0x00000000301043f0, TgtBegin=0x0000000b08c20000 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b08c20000 - is new > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Creating new map entry: HstBase=0x00000000301043f0, > HstBegin=0x00000000301043f0, HstEnd=0x000000005fbf4bf0, TgtBegin=0x0000000b38720000 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b38720000 - is new > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x0000000000613bf0, > TgtPtrBegin=0x0000000b08c20000, Size=800000000, RefCount=1 > Libomptarget --> Obtained target argument 0x0000000b08c20000 from host pointer > 0x0000000000613bf0 > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x00000000301043f0, > TgtPtrBegin=0x0000000b38720000, Size=800000000, RefCount=1 > Libomptarget --> Obtained target argument 0x0000000b38720000 from host pointer > 0x00000000301043f0 > Libomptarget --> Launching target execution __omp_offloading_2b_1890d30_main_l48 > with pointer 0x0000000060ee2ee0 (index=0). > Target CUDA RTL --> Setting CUDA threads per block to default 128 > Target CUDA RTL --> Using requested number of teams 1 > Target CUDA RTL --> Launch kernel with 1 blocks and 128 threads > Target CUDA RTL --> Launch of entry point at 0x0000000060ee2ee0 successful! > Target CUDA RTL --> Kernel execution at 0x0000000060ee2ee0 successful! > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x00000000301043f0, > TgtPtrBegin=0x0000000b38720000, Size=800000000, updated RefCount=1 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b38720000 - is last > Libomptarget --> Moving 800000000 bytes (tgt:0x0000000b38720000) -> > (hst:0x00000000301043f0) > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Deleting tgt data 0x0000000b38720000 of size 800000000 > Libomptarget --> Removing mapping with HstPtrBegin=0x00000000301043f0, > TgtPtrBegin=0x0000000b38720000, Size=800000000 > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x0000000000613bf0, > TgtPtrBegin=0x0000000b08c20000, Size=800000000, updated RefCount=1 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b08c20000 - is last > Libomptarget --> Moving 800000000 bytes (tgt:0x0000000b08c20000) -> > (hst:0x0000000000613bf0) > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Deleting tgt data 0x0000000b08c20000 of size 800000000 > Libomptarget --> Removing mapping with HstPtrBegin=0x0000000000613bf0, > TgtPtrBegin=0x0000000b08c20000, Size=800000000 > Libomptarget --> Call to omp_get_num_devices returning 1 > Number of processors: 24 > Number of devices: 1 > Default device: 0 > Is initial device: 1 > Libomptarget --> Entering target region with entry point 0x00000000004012d1 and > device Id -1 > Libomptarget --> Checking whether device 0 is ready. > Libomptarget --> Is the device 0 (local ID 0) initialized? 1 > Libomptarget --> Device 0 is ready to use. > Libomptarget --> Entry 0: Base=0x0000000000613bf0, Begin=0x0000000000613bf0, > Size=800000000, Type=0x21 > Libomptarget --> Entry 1: Base=0x00000000301043f0, Begin=0x00000000301043f0, > Size=800000000, Type=0x21 > Libomptarget --> Entry 2: Base=0x00007fff707a86e8, Begin=0x00007fff707a86e8, > Size=8, Type=0x23 > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Creating new map entry: HstBase=0x0000000000613bf0, > HstBegin=0x0000000000613bf0, HstEnd=0x00000000301043f0, TgtBegin=0x0000000b08c20000 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b08c20000 - is new > Libomptarget --> Moving 800000000 bytes (hst:0x0000000000613bf0) -> > (tgt:0x0000000b08c20000) > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Creating new map entry: HstBase=0x00000000301043f0, > HstBegin=0x00000000301043f0, HstEnd=0x000000005fbf4bf0, TgtBegin=0x0000000b38720000 > Libomptarget --> There are 800000000 bytes allocated at target address > 0x0000000b38720000 - is new > Libomptarget --> Moving 800000000 bytes (hst:0x00000000301043f0) -> > (tgt:0x0000000b38720000) > Libomptarget --> Looking up mapping(HstPtrBegin=0x00007fff707a86e8, Size=8)... > Libomptarget --> Creating new map entry: HstBase=0x00007fff707a86e8, > HstBegin=0x00007fff707a86e8, HstEnd=0x00007fff707a86f0, TgtBegin=0x0000000b68220000 > Libomptarget --> There are 8 bytes allocated at target address > 0x0000000b68220000 - is new > Libomptarget --> Moving 8 bytes (hst:0x00007fff707a86e8) -> (tgt:0x0000000b68220000) > Libomptarget --> Looking up mapping(HstPtrBegin=0x0000000000613bf0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x0000000000613bf0, > TgtPtrBegin=0x0000000b08c20000, Size=800000000, RefCount=1 > Libomptarget --> Obtained target argument 0x0000000b08c20000 from host pointer > 0x0000000000613bf0 > Libomptarget --> Looking up mapping(HstPtrBegin=0x00000000301043f0, > Size=800000000)... > Libomptarget --> Mapping exists with HstPtrBegin=0x00000000301043f0, > TgtPtrBegin=0x0000000b38720000, Size=800000000, RefCount=1 > Libomptarget --> Obtained target argument 0x0000000b38720000 from host pointer > 0x00000000301043f0 > Libomptarget --> Looking up mapping(HstPtrBegin=0x00007fff707a86e8, Size=8)... > Libomptarget --> Mapping exists with HstPtrBegin=0x00007fff707a86e8, > TgtPtrBegin=0x0000000b68220000, Size=8, RefCount=1 > Libomptarget --> Obtained target argument 0x0000000b68220000 from host pointer > 0x00007fff707a86e8 > Libomptarget --> Launching target execution __omp_offloading_2b_1890d30_main_l67 > with pointer 0x0000000060ee2e70 (index=1). > Target CUDA RTL --> Setting CUDA threads per block to default 128 > Target CUDA RTL --> Using requested number of teams 1 > Target CUDA RTL --> Launch kernel with 1 blocks and 128 threads > Target CUDA RTL --> Launch of entry point at 0x0000000060ee2e70 successful! > Target CUDA RTL --> Kernel execution error at 0x0000000060ee2e70! > Target CUDA RTL --> CUDA error is: an illegal memory access was encountered > Libomptarget --> Executing target region abort target. > Libomptarget fatal error 1: failure of target construct while offloading is > mandatory > Libomptarget --> Unloading target library! > Libomptarget --> Image 0x0000000000602090 is compatible with RTL 0x00000000609f95d0! > Libomptarget --> Unregistered image 0x0000000000602090 from RTL 0x00000000609f95d0! > Libomptarget --> Done unregistering images! > Libomptarget --> Removing translation table for descriptor 0x0000000000613b90 > Libomptarget --> Done unregistering library! > Target CUDA RTL --> Error when unloading CUDA module > Target CUDA RTL --> CUDA error is: an illegal memory access was encountered > loki introduction 119 > > > Thank you very much for your help in advance. > > > Best regards > > Siegmar > > > > >> >> George >> >> -------------------------------------------------------------------------------- >> *From:* Openmp-dev <openmp-dev-bounces(a)lists.llvm.org> on behalf of Siegmar >> Gross via Openmp-dev <openmp-dev(a)lists.llvm.org> >> *Sent:* 01 October 2018 13:26 >> *To:* llvm-openmp-dev >> *Subject:* [Openmp-dev] Libomptarget fatal error 1: failure of target construct >> while offloading is mandatory >> Hi, >> >> today I've installed llvm-trunk. Unfortunately, I get an error for one of my >> programs. >> >> >> loki introduction 110 clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda >> dot_prod_accelerator_OpenMP.c >> loki introduction 111 a.out >> Number of processors: 24 >> Number of devices: 1 >> Default device: 0 >> Is initial device: 1 >> Libomptarget fatal error 1: failure of target construct while offloading is >> mandatory >> >> loki introduction 112 setenv OMP_DEFAULT_DEVICE 1 >> loki introduction 113 a.out >> Libomptarget fatal error 1: failure of target construct while offloading is >> mandatory >> >> loki introduction 114 clang -v >> clang version 8.0.0 (trunk 343447) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> InstalledDir: /usr/local/llvm-trunk/bin >> Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 >> Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 >> Candidate multilib: .;@m64 >> Candidate multilib: 32;@m32 >> Selected multilib: .;@m64 >> Found CUDA installation: /usr/local/cuda-9.0, version 9.0 >> loki introduction 115 >> >> >> >> The program works fine with llvm-7.0.0. >> >> loki introduction 125 clang -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda >> dot_prod_accelerator_OpenMP.c >> loki introduction 126 a.out >> Number of processors: 24 >> Number of devices: 1 >> Default device: 0 >> Is initial device: 1 >> sum = 6.000000e+08 >> >> loki introduction 127 setenv OMP_DEFAULT_DEVICE 1 >> loki introduction 128 a.out >> Number of processors: 24 >> Number of devices: 1 >> Default device: 1 >> Is initial device: 1 >> sum = 6.000000e+08 >> >> loki introduction 129 clang -v >> clang version 7.0.0 (tags/RELEASE_700/final) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> InstalledDir: /usr/local/llvm-7.0.0/bin >> Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 >> Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/4.8 >> Candidate multilib: .;@m64 >> Candidate multilib: 32;@m32 >> Selected multilib: .;@m64 >> Found CUDA installation: /usr/local/cuda-9.0, version 9.0 >> loki introduction 130 >> >> >> Hopefully somebody can fix the problem. Do you need anything else to locate the >> error? Thank you very much for any help in advance. >> >> >> Kind regards >> >> Siegmar _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0