April 2016 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPICH 3.2 failing in MPI_Init
by Andrew Wood 07 Apr '16

07 Apr '16

I've now tried using the MPICH-built version of mpiexec, but using our desktops as nodes, instead of our cluster. The job runs successfully in that case. Andy. On 07/04/16 16:59, Andrew Wood wrote: > Thanks for the response. > > Using the MPICH-built mpiexec gives this error message: > > ssh_askpass: exec(/usr/lib/ssh/ksshaskpass): No such file or directory > Host key verification failed. > > > which presumably means I'd have to do something with the ssh configuration on > the nodes. The same error occurs with MPICH 3.1.4, but like I said, MPICH 3.1.4 > works fine with mpiexec 0.84. > > Andy. > > > > On 07/04/16 15:55, Kenneth Raffenetti wrote: >> Just to be sure, can you use the mpiexec that is built/installed with MPICH 3.2? >> You mention mpiexec version 0.84 below, so that's the first thing I would try. >> >> Ken >> >> On 04/07/2016 05:49 AM, Andrew Wood wrote: >>> Hi, >>> >>> I'm trying to get MPICH 3.2 working on our cluster, but jobs are failing in >>> MPI_Init with the following output if they are run on two or more nodes (4 >>> processes per node): >>> >>> >>> Fatal error in MPI_Init: Other MPI error, error stack: >>> MPIR_Init_thread(490).................: >>> MPID_Init(201)........................: channel initialization failed >>> MPIDI_CH3_Init(93)....................: >>> MPID_nem_init(285)....................: >>> MPIDI_CH3I_Seg_commit(366)............: >>> MPIU_SHMW_Hnd_deserialize(324)........: >>> MPIU_SHMW_Seg_open(867)...............: >>> MPIU_SHMW_Seg_create_attach_templ(638): open failed - No such file or directory >>> mpiexec: Error: handle_pmi: unknown cmd abort. >>> >>> >>> >>> The full output above only occurs intermittently. Sometimes only the last line >>> appears (job aborted before stderr is flushed?). >>> >>> >>> >>> Our cluster uses Torque 2.5.13 and Maui 3.3.1, and the jobs are launched with >>> mpiexec 0.84. >>> >>> >>> >>> I've configured MPICH as follows. >>> >>> ./configure --enable-error-checking=all --enable-error-messages=all >>> --enable-g=all --disable-fast --enable-check-compiler-flags --enable-fortran=all >>> --enable-cxx --enable-romio --enable-debuginfo --enable-versioning >>> --enable-strict >>> >>> >>> >>> I've found the problem goes away if I include the option >>> '--enable-nemesis-dbg-nolocal', but presumably that could have an impact on >>> performance. >>> >>> >>> The problem doesn't occur with MPICH 3.1.4, configured with the same options. >>> >>> >>> I've found this message in the mailing list archives, reporting the same problem >>> http://lists.mpich.org/pipermail/discuss/2015-December/004352.html >>> However, that was on a system using SLURM, and the replies suggest that the >>> problem was with SLURM rather than MPICH, and we're not using SLURM on our >>> system. >>> >>> Can anyone help? >>> >>> >>> Regards, >>> Andy. >>> >>> >> . >> > > -- Dr Andrew Wood Fluid Gravity Engineering Ltd. 83 Market Street St Andrews Fife KY16 9NX Tel: +44 (0)1334 460805 Fax: +44 (0)1334 460813 Fluid Gravity Engineering Ltd is registered in the UK with registration number 1674369. The registered address is Fluid Gravity Engineering Ltd, Unit 1, The Old Coach House, 1 West Street, Emsworth, Hampshire, PO10 7DX.

1 0

Re: [mpich-discuss] MPICH 3.2 failing in MPI_Init
by Andrew Wood 07 Apr '16

07 Apr '16

Thanks for the response. Using the MPICH-built mpiexec gives this error message: ssh_askpass: exec(/usr/lib/ssh/ksshaskpass): No such file or directory Host key verification failed. which presumably means I'd have to do something with the ssh configuration on the nodes. The same error occurs with MPICH 3.1.4, but like I said, MPICH 3.1.4 works fine with mpiexec 0.84. Andy. On 07/04/16 15:55, Kenneth Raffenetti wrote: > Just to be sure, can you use the mpiexec that is built/installed with MPICH 3.2? > You mention mpiexec version 0.84 below, so that's the first thing I would try. > > Ken > > On 04/07/2016 05:49 AM, Andrew Wood wrote: >> Hi, >> >> I'm trying to get MPICH 3.2 working on our cluster, but jobs are failing in >> MPI_Init with the following output if they are run on two or more nodes (4 >> processes per node): >> >> >> Fatal error in MPI_Init: Other MPI error, error stack: >> MPIR_Init_thread(490).................: >> MPID_Init(201)........................: channel initialization failed >> MPIDI_CH3_Init(93)....................: >> MPID_nem_init(285)....................: >> MPIDI_CH3I_Seg_commit(366)............: >> MPIU_SHMW_Hnd_deserialize(324)........: >> MPIU_SHMW_Seg_open(867)...............: >> MPIU_SHMW_Seg_create_attach_templ(638): open failed - No such file or directory >> mpiexec: Error: handle_pmi: unknown cmd abort. >> >> >> >> The full output above only occurs intermittently. Sometimes only the last line >> appears (job aborted before stderr is flushed?). >> >> >> >> Our cluster uses Torque 2.5.13 and Maui 3.3.1, and the jobs are launched with >> mpiexec 0.84. >> >> >> >> I've configured MPICH as follows. >> >> ./configure --enable-error-checking=all --enable-error-messages=all >> --enable-g=all --disable-fast --enable-check-compiler-flags --enable-fortran=all >> --enable-cxx --enable-romio --enable-debuginfo --enable-versioning >> --enable-strict >> >> >> >> I've found the problem goes away if I include the option >> '--enable-nemesis-dbg-nolocal', but presumably that could have an impact on >> performance. >> >> >> The problem doesn't occur with MPICH 3.1.4, configured with the same options. >> >> >> I've found this message in the mailing list archives, reporting the same problem >> http://lists.mpich.org/pipermail/discuss/2015-December/004352.html >> However, that was on a system using SLURM, and the replies suggest that the >> problem was with SLURM rather than MPICH, and we're not using SLURM on our >> system. >> >> Can anyone help? >> >> >> Regards, >> Andy. >> >> > . > -- Dr Andrew Wood Fluid Gravity Engineering Ltd. 83 Market Street St Andrews Fife KY16 9NX Tel: +44 (0)1334 460805 Fax: +44 (0)1334 460813 Fluid Gravity Engineering Ltd is registered in the UK with registration number 1674369. The registered address is Fluid Gravity Engineering Ltd, Unit 1, The Old Coach House, 1 West Street, Emsworth, Hampshire, PO10 7DX.

1 0

Re: [mpich-discuss] gcc 6.0 miscompiles mpich ?
by Balaji, Pavan 07 Apr '16

07 Apr '16

Sorry, 3.2.1 got delayed a bit. It should be out "soon". -- Pavan > On Apr 7, 2016, at 4:18 AM, VandeVondele Joost <joost.vandevondele(a)mat.ethz.ch> wrote: > > I have tried to reproduce that with mpich 3.2, and it does not. However, looks like the macro MPIDI_Request_create_sreq changed quite a bit between mpich 3.1 and 3.2, so it is not a surprise. At least, it is a practical solution. > > I was wondering when 3.2.1 will be released, I contains a fix for a problem I reported with 3.2. The timeline suggests it is due. > > Thanks, > > Joost > _______________________________________________ > 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] MPICH 3.2 failing in MPI_Init
by Kenneth Raffenetti 07 Apr '16

07 Apr '16

Just to be sure, can you use the mpiexec that is built/installed with MPICH 3.2? You mention mpiexec version 0.84 below, so that's the first thing I would try. Ken On 04/07/2016 05:49 AM, Andrew Wood wrote: > Hi, > > I'm trying to get MPICH 3.2 working on our cluster, but jobs are failing in > MPI_Init with the following output if they are run on two or more nodes (4 > processes per node): > > > Fatal error in MPI_Init: Other MPI error, error stack: > MPIR_Init_thread(490).................: > MPID_Init(201)........................: channel initialization failed > MPIDI_CH3_Init(93)....................: > MPID_nem_init(285)....................: > MPIDI_CH3I_Seg_commit(366)............: > MPIU_SHMW_Hnd_deserialize(324)........: > MPIU_SHMW_Seg_open(867)...............: > MPIU_SHMW_Seg_create_attach_templ(638): open failed - No such file or directory > mpiexec: Error: handle_pmi: unknown cmd abort. > > > > The full output above only occurs intermittently. Sometimes only the last line > appears (job aborted before stderr is flushed?). > > > > Our cluster uses Torque 2.5.13 and Maui 3.3.1, and the jobs are launched with > mpiexec 0.84. > > > > I've configured MPICH as follows. > > ./configure --enable-error-checking=all --enable-error-messages=all > --enable-g=all --disable-fast --enable-check-compiler-flags --enable-fortran=all > --enable-cxx --enable-romio --enable-debuginfo --enable-versioning --enable-strict > > > > I've found the problem goes away if I include the option > '--enable-nemesis-dbg-nolocal', but presumably that could have an impact on > performance. > > > The problem doesn't occur with MPICH 3.1.4, configured with the same options. > > > I've found this message in the mailing list archives, reporting the same problem > http://lists.mpich.org/pipermail/discuss/2015-December/004352.html > However, that was on a system using SLURM, and the replies suggest that the > problem was with SLURM rather than MPICH, and we're not using SLURM on our system. > > Can anyone help? > > > Regards, > Andy. > > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPICH 3.2 failing in MPI_Init
by Andrew Wood 07 Apr '16

07 Apr '16

Hi, I'm trying to get MPICH 3.2 working on our cluster, but jobs are failing in MPI_Init with the following output if they are run on two or more nodes (4 processes per node): Fatal error in MPI_Init: Other MPI error, error stack: MPIR_Init_thread(490).................: MPID_Init(201)........................: channel initialization failed MPIDI_CH3_Init(93)....................: MPID_nem_init(285)....................: MPIDI_CH3I_Seg_commit(366)............: MPIU_SHMW_Hnd_deserialize(324)........: MPIU_SHMW_Seg_open(867)...............: MPIU_SHMW_Seg_create_attach_templ(638): open failed - No such file or directory mpiexec: Error: handle_pmi: unknown cmd abort. The full output above only occurs intermittently. Sometimes only the last line appears (job aborted before stderr is flushed?). Our cluster uses Torque 2.5.13 and Maui 3.3.1, and the jobs are launched with mpiexec 0.84. I've configured MPICH as follows. ./configure --enable-error-checking=all --enable-error-messages=all --enable-g=all --disable-fast --enable-check-compiler-flags --enable-fortran=all --enable-cxx --enable-romio --enable-debuginfo --enable-versioning --enable-strict I've found the problem goes away if I include the option '--enable-nemesis-dbg-nolocal', but presumably that could have an impact on performance. The problem doesn't occur with MPICH 3.1.4, configured with the same options. I've found this message in the mailing list archives, reporting the same problem http://lists.mpich.org/pipermail/discuss/2015-December/004352.html However, that was on a system using SLURM, and the replies suggest that the problem was with SLURM rather than MPICH, and we're not using SLURM on our system. Can anyone help? Regards, Andy. -- Dr Andrew Wood Fluid Gravity Engineering Ltd. 83 Market Street St Andrews Fife KY16 9NX Tel: +44 (0)1334 460805 Fax: +44 (0)1334 460813 Fluid Gravity Engineering Ltd is registered in the UK with registration number 1674369. The registered address is Fluid Gravity Engineering Ltd, Unit 1, The Old Coach House, 1 West Street, Emsworth, Hampshire, PO10 7DX. _______________________________________________ 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] gcc 6.0 miscompiles mpich ?
by VandeVondele Joost 07 Apr '16

07 Apr '16

I have tried to reproduce that with mpich 3.2, and it does not. However, looks like the macro MPIDI_Request_create_sreq changed quite a bit between mpich 3.1 and 3.2, so it is not a surprise. At least, it is a practical solution. I was wondering when 3.2.1 will be released, I contains a fix for a problem I reported with 3.2. The timeline suggests it is due. Thanks, Joost _______________________________________________ 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] gcc 6.0 miscompiles mpich ?
by VandeVondele Joost 07 Apr '16

07 Apr '16

Hi Halim, Jeff, just to clarify, current gcc trunk is in stage 4 (last regression fixing phase before release, https://gcc.gnu.org/ml/gcc/2016-03/msg00108.html) which is the last moment to report bugs in the hope of getting them fixed before release. I ran into this issue as I have started extensive prerelease gcc testing for our project (cp2k), including a recompilation of all dependencies, which includes mpich. I'm actually also gcc maintainer (mostly Fortran related), so I'm used to file the bug reports, and I know that a good testcase will be the starting point. The issue is in mpich, as the recompilation with the mentioned options is of the mpich libraries only, the user binary remains the same (dynamically linked). So, what I'm hoping is that somebody on the mpich team could try to reproduce this to analyze this in more depth. Thanks, Joost ________________________________________ From: Halim Amer [aamer(a)anl.gov] Sent: Wednesday, April 06, 2016 9:26 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] gcc 6.0 miscompiles mpich ? > If changing compiler flags alone causes MPICH to go from working to > nonworking, it's hard not to blame the compiler. It won't be the first time a bug shows-up/disappears when changing compiler flags, and many times the compiler wasn't the culprit. My point is that we need more information to isolate the problem. If the bug is in the user code or MPICH, we shouldn't bother the gcc folks. --Halim www.mcs.anl.gov/~aamer On 4/6/16 12:31 PM, Jeff Hammond wrote: > > > On Wed, Apr 6, 2016 at 9:32 AM, Halim Amer <aamer(a)anl.gov > <mailto:[email protected]>> wrote: > > This information is insufficient to blame the compiler. > > > This statement sure seems sufficient to me: > > "mpich gets miscompiled when building with CFLAGS='-O2 -ftree-vectorize > -g' (but not with just -O2 -g or -O3 -g)." > > If changing compiler flags alone causes MPICH to go from working to > nonworking, it's hard not to blame the compiler. > > Of course, if the app flags changed, then all bets are off. > > Anyways, I concur that using the latest development tree of a compiler > isn't a good idea. I'm sure the GCC folks would readily admit that > there are bugs in the trunk. It never hurts to file this bug, but if > there is no MCVE, it will be hard for anyone to make progress. > > Jeff > > We don't know if the user (application code), MPICH, or gcc is doing > something wrong. > > First, you need to use a stable compiler version (not trunk) and a > recent MPICH (3.2 not the old 3.1 version). > > Second, you need to make sure the user code is not doing something > wrong (e.g. MPI_Alltoall could have gotten an invalid buffer address > or count). If you send us a toy program that reproduces the problem, > we could help with this. > > --Halim > www.mcs.anl.gov/~aamer <http://www.mcs.anl.gov/~aamer> > > > On 4/6/16 10:24 AM, VandeVondele Joost wrote: > > Hi, > > when compiling mpich-3.1.2 using gcc trunk (which will be gcc > 6.0 in a > couple of days/weeks), I noticed mpich gets miscompiled when > building > with CFLAGS='-O2 -ftree-vectorize -g' (but not with just -O2 -g > or -O3 -g). > > I believe that the miscompilation happens with the macro > MPIDI_Request_create_sreq since a typical trace looks like: > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x33ac83269f in ??? > #1 0x7f3743953d69 in MPIDI_Isend_self > at src/mpid/ch3/src/mpidi_isend_self.c:34 > #2 0x7f374394dfa3 in MPID_Isend > at src/mpid/ch3/src/mpid_isend.c:55 > #3 0x7f374390793a in MPIC_Isend > at src/mpi/coll/helper_fns.c:646 > #4 0x7f37438628c5 in MPIR_Alltoall_intra > at src/mpi/coll/alltoall.c:520 > #5 0x7f374386376e in MPIR_Alltoall > at src/mpi/coll/alltoall.c:726 > #6 0x7f3743863827 in MPIR_Alltoall_impl > at src/mpi/coll/alltoall.c:761 > #7 0x7f3743863e7a in PMPI_Alltoall > at src/mpi/coll/alltoall.c:884 > #8 0x7f37424181bf in pmpi_alltoall_ > at src/binding/fortran/mpif_h/alltoallf.c:272 > > I don't know mpich well enough to extract a testcase, but it > would be > great if somebody could extract that and report to the gcc team (I'm > happy to do the reporting if needed). > > thanks in advance, > > Joost > > > > _______________________________________________ > 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 > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > 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 _______________________________________________ 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 for IBM POWER8
by Balaji, Pavan 06 Apr '16

06 Apr '16

Can you disable hcoll with the following configure option "--without-hcoll". -- Pavan > On Apr 6, 2016, at 4:22 PM, Xing Liu <xing.research(a)gmail.com> wrote: > > Hello, > > I was trying to compile MPICH on IBM POWER8 system and got the following error message. Anyone know how to fix it? Thanks > > src/mpid/common/hcoll/hcoll_rte.c:63:33: error: too few arguments to function call, single argument 'made_progress' was not specified > ret = hcoll_do_progress(); > ~~~~~~~~~~~~~~~~~ ^ > src/mpid/common/hcoll/hcoll.h:39:1: note: 'hcoll_do_progress' declared here > int hcoll_do_progress(int *made_progress); > ^ > src/mpid/common/hcoll/hcoll_rte.c:297:48: error: no member named 'vcrt' in 'struct MPID_Comm' > ec_handles[i].handle = (void *) (comm->vcrt->vcr_table[ec_indexes[i]]); > ~~~~ ^ > src/mpid/common/hcoll/hcoll_rte.c:311:41: error: no member named 'vcrt' in 'struct MPID_Comm' > ec_handle->handle = (void *) (comm->vcrt->vcr_table[my_rank]); > ~~~~ ^ > 3 errors generated. > Error while processing src/mpid/common/hcoll/hcoll_rte.c. > make[2]: *** [src/mpid/common/hcoll/lib_libmpi_la-hcoll_rte.lo] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > Xing > _______________________________________________ > 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

MPICH for IBM POWER8
by Xing Liu 06 Apr '16

06 Apr '16

Hello, I was trying to compile MPICH on IBM POWER8 system and got the following error message. Anyone know how to fix it? Thanks src/mpid/common/hcoll/hcoll_rte.c:63:33: error: too few arguments to function call, single argument 'made_progress' was not specified ret = hcoll_do_progress(); ~~~~~~~~~~~~~~~~~ ^ src/mpid/common/hcoll/hcoll.h:39:1: note: 'hcoll_do_progress' declared here int hcoll_do_progress(int *made_progress); ^ src/mpid/common/hcoll/hcoll_rte.c:297:48: error: no member named 'vcrt' in 'struct MPID_Comm' ec_handles[i].handle = (void *) (comm->vcrt->vcr_table[ec_ indexes[i]]); ~~~~ ^ src/mpid/common/hcoll/hcoll_rte.c:311:41: error: no member named 'vcrt' in 'struct MPID_Comm' ec_handle->handle = (void *) (comm->vcrt->vcr_table[my_rank]); ~~~~ ^ 3 errors generated. Error while processing src/mpid/common/hcoll/hcoll_rte.c. make[2]: *** [src/mpid/common/hcoll/lib_libmpi_la-hcoll_rte.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Xing _______________________________________________ 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] gcc 6.0 miscompiles mpich ?
by Halim Amer 06 Apr '16

06 Apr '16

> If changing compiler flags alone causes MPICH to go from working to > nonworking, it's hard not to blame the compiler. It won't be the first time a bug shows-up/disappears when changing compiler flags, and many times the compiler wasn't the culprit. My point is that we need more information to isolate the problem. If the bug is in the user code or MPICH, we shouldn't bother the gcc folks. --Halim www.mcs.anl.gov/~aamer On 4/6/16 12:31 PM, Jeff Hammond wrote: > > > On Wed, Apr 6, 2016 at 9:32 AM, Halim Amer <aamer(a)anl.gov > <mailto:[email protected]>> wrote: > > This information is insufficient to blame the compiler. > > > This statement sure seems sufficient to me: > > "mpich gets miscompiled when building with CFLAGS='-O2 -ftree-vectorize > -g' (but not with just -O2 -g or -O3 -g)." > > If changing compiler flags alone causes MPICH to go from working to > nonworking, it's hard not to blame the compiler. > > Of course, if the app flags changed, then all bets are off. > > Anyways, I concur that using the latest development tree of a compiler > isn't a good idea. I'm sure the GCC folks would readily admit that > there are bugs in the trunk. It never hurts to file this bug, but if > there is no MCVE, it will be hard for anyone to make progress. > > Jeff > > We don't know if the user (application code), MPICH, or gcc is doing > something wrong. > > First, you need to use a stable compiler version (not trunk) and a > recent MPICH (3.2 not the old 3.1 version). > > Second, you need to make sure the user code is not doing something > wrong (e.g. MPI_Alltoall could have gotten an invalid buffer address > or count). If you send us a toy program that reproduces the problem, > we could help with this. > > --Halim > www.mcs.anl.gov/~aamer <http://www.mcs.anl.gov/~aamer> > > > On 4/6/16 10:24 AM, VandeVondele Joost wrote: > > Hi, > > when compiling mpich-3.1.2 using gcc trunk (which will be gcc > 6.0 in a > couple of days/weeks), I noticed mpich gets miscompiled when > building > with CFLAGS='-O2 -ftree-vectorize -g' (but not with just -O2 -g > or -O3 -g). > > I believe that the miscompilation happens with the macro > MPIDI_Request_create_sreq since a typical trace looks like: > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x33ac83269f in ??? > #1 0x7f3743953d69 in MPIDI_Isend_self > at src/mpid/ch3/src/mpidi_isend_self.c:34 > #2 0x7f374394dfa3 in MPID_Isend > at src/mpid/ch3/src/mpid_isend.c:55 > #3 0x7f374390793a in MPIC_Isend > at src/mpi/coll/helper_fns.c:646 > #4 0x7f37438628c5 in MPIR_Alltoall_intra > at src/mpi/coll/alltoall.c:520 > #5 0x7f374386376e in MPIR_Alltoall > at src/mpi/coll/alltoall.c:726 > #6 0x7f3743863827 in MPIR_Alltoall_impl > at src/mpi/coll/alltoall.c:761 > #7 0x7f3743863e7a in PMPI_Alltoall > at src/mpi/coll/alltoall.c:884 > #8 0x7f37424181bf in pmpi_alltoall_ > at src/binding/fortran/mpif_h/alltoallf.c:272 > > I don't know mpich well enough to extract a testcase, but it > would be > great if somebody could extract that and report to the gcc team (I'm > happy to do the reporting if needed). > > thanks in advance, > > Joost > > > > _______________________________________________ > 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 > > > > > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ > > > _______________________________________________ > 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