January 2021 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Is it okay to remove F77 support?
by Håkon Strandenes 27 Jan '21

27 Jan '21

You must differentiate between Fortran 77 and fixed-form Fortran source code. I doubt there are any true Fortran 77 code around today. I am myself maintaining a large codebase written in Fixed Form Fortran. The code was probably Fortran 77 at some point 30-40 years ago, but not any more. Yet we still maintain parts in Fixed Form, though. This code is Fortran 2003 at minimum. I do not have the Fortran 2018 standard document around, but at least Fortran 2008 include fixed-form as an allowed source form (although marked as deprecated). For those interested, this is chapter 3.3 "Source form" in ISO/IEC 1539-1:2010. F77 can only be fixed form, but that does not make any fixed-form Fortran program F77. Fixed-form Fortran can be F2008 as well. This must be understood correctly for this discussion to be fruitful. Best regards, Håkon Den 2021-01-27 04:08, skrev Gus Correa via discuss: > IS IT OKAY TO REMOVE F77 SUPPORT? > > No, NO, NO!!!! NO! > > Removing the support to Fortran 77 from MPI is a disastrous idea! > Sorry to say, but it is really stupid to suppose that only because > compilers support F90 > that you can remove F77 support from MPI. > A lot of people, academic institutions, and probably industry, > continue to use, > and develop new code in F77. > > What matters is if the CODE is written in Fortran 90 or in Fortran 77, > and whether it uses the Fortran 77 MPI API or the Fortran 90 MPI API, > not whether the compiler supports Fortran 90 (and yes, if not all, > do). > > There is an enormous Fortran 77 code base, written using MPI, and that > is not likely to change for the foreseeable future. > That is true in the Atmospheric/Climate/Ocean sciences, where I work, > > > but would guess this is true in other areas of science as well. > Just one example: The MITgcm, which has an huge community of users, > > is the backbone for many research projects, supports many PhD thesis, > is 100% written in Fortran-77 and will not be changed anytime soon, > as there is no financial support to do that. > > Also, this type of inquiry to the MPICH community is way too narrow. > I don't think you should be using emails on a mailing list to base > such a consequential decision. > Argonne should know better which community it supports, which codes > out there use MPI. > > Thank you, > > Gus Correa > Lamont-Doherty Earth Observatory of Columbia University. > > On Tue, Jan 26, 2021 at 6:12 PM Zhou, Hui via discuss > <discuss(a)mpich.org> wrote: > >> Dear MPICH community, >> >> Can we assume at this point of time, that every Fortran compiler out >> there supports Fortran 90 at least? >> >> -- >> Hui Zhou >> >> _______________________________________________ >> 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] Questions about MPICH multi-thread support
by Guilherme Valarini 27 Jan '21

27 Jan '21

Thanks for the answer. I would like to ask just some follow-up questions though. *Question 1.* In our application there are two modules that run concurrently and rely on MPI (using two different communicators for isolation purposes). During the development time we observed the following behavior: when one of the modules sends a large buffer (say +1GB), the other one encountered a kind of contention problem where its messages were held back through the duration of the large data transfer, even though second module messages were really small. Is this a known behavior? Is there any kind of message fragmentation implemented in MPICH that would allow concurrent message progression? If not, are there any plans to implement such a feature? *Question 2.* We already have used one of the scenarios described in the previous email, where one thread of a process A sends a message to one of multiple threads on a process B, all of which are waiting on the same message triple through non-blocking receives. The expected behaviour would be that only one of the threads from process B would receive the message, but, during our tests we have faced a failure where a segfault would be thrown from inside *MPI_Recv *function at one of the receiving threads. Is the expected behavior correct? Is there any known issue with this use case that would trigger the described problem? I know this can probably be the application's fault, I just want to check if there is any known issue on the matter. Thanks, Guilherme Valarini Em ter., 26 de jan. de 2021 às 18:55, Zhou, Hui <zhouh(a)anl.gov> escreveu: > > > > *Question 1*. I am aware of the message envelope tuples (source, > destination, tag, communicator) that may be used to identify and filter > different messages. While using MPICH, can I rely on such information in > order to guarantee that the correct messages will reach/be matched with > their destinations in a multiprocess multithreaded program? > > > > Yes, you can rely on the correctness of MPI implementation. That is, if > your `rank, tag, communicator` matches the messages correctly to your > intention, then you can trust that a correct implementation will do that > even in a multi-threaded setting. > > > > The care need be taken that when your `rank, tag, ,communicator` doesn’t > uniquely match, and if you send or receive in different threads, the order > of matching is not certain, and it may surprise you. But that is just the > perils of concurrent programming. > > > > > *Question 2*. Is there a problem when mixing blocking and non-blocking > calls on opposite sides of a message? Even in the multithreaded scenarios > described previously? (e.g. matching a *MPI_Isend* with a *MPI_Recv*, and > vice-versa.) > > > > No, there is no problem in that. > > > > -- > Hui Zhou > > > > > > *From: *Guilherme Valarini via discuss <discuss(a)mpich.org> > *Date: *Tuesday, January 26, 2021 at 3:24 PM > *To: *discuss(a)mpich.org <discuss(a)mpich.org> > *Cc: *Guilherme Valarini <guilherme.a.valarini(a)gmail.com> > *Subject: *[mpich-discuss] Questions about MPICH multi-thread support > > Dear MPICH community, > > > > I am currently developing an event system built upon MPI and I have a few > questions about the current state of multi-thread support from MPICH in the > *MPI_THREAD_MULTIPLE* mode. > > > > *Question 1*. I am aware of the message envelope tuples (source, > destination, tag, communicator) that may be used to identify and filter > different messages. While using MPICH, can I rely on such information in > order to guarantee that the correct messages will reach/be matched with > their destinations in a multiprocess multithreaded program? I know this is > quite a broad question, but I am more interested in the analysis of the > following scenarios. > > > > - Two threads in a process A want to send different messages to two > different processes, B and C (each with one thread), while using the > *same* *communicator* *and* *tag*. Code example: > > // One process with N threads to N process with one thread (same tag) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 2, 0, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > } > > > - The same scenario as above, but now each thread uses a *different > tag* to communicate to their respective process while only sharing the > *same* *communicator*. Code example: > > // One process with N threads to N process with one thread (different > tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 2, 2, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else { > MPI_Recv(data, 1, MPI_CHAR, 0, rank, MPI_COMM_WORLD, > MPI_STATUS_IGNORE); > } > > > - Multiple threads from a process A want each to send a message to the > same thread of another process B using the *same communicator and* > *tag*. Code example: > > // One process with N threads to one process with one thread (same tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else if (rank == 1) { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > } > > > - One thread from a process A wants to send a message to one of > multiple threads from a process B using the *same communicator and tag*. > Code example: > > // One process with one thread to one process with N threads (same tags) > if (rank == 0) { > MPI_Request requests[2]; > // Generate data ... > MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[0]); > // Generate data ... > MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[1]); > > MPI_Waitall(2, requests, MPI_STATUSES_IGNORE); > } else if (rank == 1) { > std::thread t1([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > std::thread t2([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > t1.join(); t2.join(); > } > > > - Two threads from a process A want each to send a message to two > threads from a process B using different tags for each pair of threads > (e.g. the pair A.1/B.1 uses a different tag from pair A.2/B.2). Code > example: > > // One process with N threads to one process with N thread (different > tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 2, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else if (rank == 1) { > std::thread t1([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 1, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > std::thread t2([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 2, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > t1.join(); t2.join(); > } > > > > *Question 2*. Is there a problem when mixing blocking and non-blocking > calls on opposite sides of a message? Even in the multithreaded scenarios > described previously? (e.g. matching a *MPI_Isend* with a *MPI_Recv*, and > vice-versa.) > > > > Thank you. > > > > Regards, > > Guilherme Valarini > > > > >

1 0

Re: [mpich-discuss] Is it okay to remove F77 support?
by Gus Correa 26 Jan '21

26 Jan '21

Is it okay to remove F77 support? No, NO, NO!!!! NO! Removing the support to Fortran 77 from MPI is a disastrous idea! Sorry to say, but it is really stupid to suppose that only because compilers support F90 that you can remove F77 support from MPI. A lot of people, academic institutions, and probably industry, continue to use, and develop new code in F77. What matters is if the CODE is written in Fortran 90 or in Fortran 77, and whether it uses the Fortran 77 MPI API or the Fortran 90 MPI API, not whether the compiler supports Fortran 90 (and yes, if not all, do). There is an enormous Fortran 77 code base, written using MPI, and that is not likely to change for the foreseeable future. That is true in the Atmospheric/Climate/Ocean sciences, where I work, but would guess this is true in other areas of science as well. Just one example: The MITgcm, which has an huge community of users, is the backbone for many research projects, supports many PhD thesis, is 100% written in Fortran-77 and will not be changed anytime soon, as there is no financial support to do that. Also, this type of inquiry to the MPICH community is way too narrow. I don't think you should be using emails on a mailing list to base such a consequential decision. Argonne should know better which community it supports, which codes out there use MPI. Thank you, Gus Correa Lamont-Doherty Earth Observatory of Columbia University. On Tue, Jan 26, 2021 at 6:12 PM Zhou, Hui via discuss <discuss(a)mpich.org> wrote: > Dear MPICH community, > > > > Can we assume at this point of time, that every Fortran compiler out there > supports Fortran 90 at least? > > > > -- > Hui Zhou > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Is it okay to remove F77 support?
by Zhou, Hui 26 Jan '21

26 Jan '21

Dear MPICH community, Can we assume at this point of time, that every Fortran compiler out there supports Fortran 90 at least? -- Hui Zhou

1 0

Re: [mpich-discuss] Questions about MPICH multi-thread support
by Zhou, Hui 26 Jan '21

26 Jan '21

> Question 1. I am aware of the message envelope tuples (source, destination, tag, communicator) that may be used to identify and filter different messages. While using MPICH, can I rely on such information in order to guarantee that the correct messages will reach/be matched with their destinations in a multiprocess multithreaded program? Yes, you can rely on the correctness of MPI implementation. That is, if your `rank, tag, communicator` matches the messages correctly to your intention, then you can trust that a correct implementation will do that even in a multi-threaded setting. The care need be taken that when your `rank, tag, ,communicator` doesn’t uniquely match, and if you send or receive in different threads, the order of matching is not certain, and it may surprise you. But that is just the perils of concurrent programming. > Question 2. Is there a problem when mixing blocking and non-blocking calls on opposite sides of a message? Even in the multithreaded scenarios described previously? (e.g. matching a MPI_Isend with a MPI_Recv, and vice-versa.) No, there is no problem in that. -- Hui Zhou From: Guilherme Valarini via discuss <discuss(a)mpich.org> Date: Tuesday, January 26, 2021 at 3:24 PM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Guilherme Valarini <guilherme.a.valarini(a)gmail.com> Subject: [mpich-discuss] Questions about MPICH multi-thread support Dear MPICH community, I am currently developing an event system built upon MPI and I have a few questions about the current state of multi-thread support from MPICH in the MPI_THREAD_MULTIPLE mode. Question 1. I am aware of the message envelope tuples (source, destination, tag, communicator) that may be used to identify and filter different messages. While using MPICH, can I rely on such information in order to guarantee that the correct messages will reach/be matched with their destinations in a multiprocess multithreaded program? I know this is quite a broad question, but I am more interested in the analysis of the following scenarios. * Two threads in a process A want to send different messages to two different processes, B and C (each with one thread), while using the same communicator and tag. Code example: // One process with N threads to N process with one thread (same tag) if (rank == 0) { std::thread t1([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); }); std::thread t2([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 2, 0, MPI_COMM_WORLD); }); t1.join(); t2.join(); } else { MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); } * The same scenario as above, but now each thread uses a different tag to communicate to their respective process while only sharing the same communicator. Code example: // One process with N threads to N process with one thread (different tags) if (rank == 0) { std::thread t1([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); }); std::thread t2([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 2, 2, MPI_COMM_WORLD); }); t1.join(); t2.join(); } else { MPI_Recv(data, 1, MPI_CHAR, 0, rank, MPI_COMM_WORLD, MPI_STATUS_IGNORE); } * Multiple threads from a process A want each to send a message to the same thread of another process B using the same communicator and tag. Code example: // One process with N threads to one process with one thread (same tags) if (rank == 0) { std::thread t1([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); }); std::thread t2([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); }); t1.join(); t2.join(); } else if (rank == 1) { MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... } * One thread from a process A wants to send a message to one of multiple threads from a process B using the same communicator and tag. Code example: // One process with one thread to one process with N threads (same tags) if (rank == 0) { MPI_Request requests[2]; // Generate data ... MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[0]); // Generate data ... MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[1]); MPI_Waitall(2, requests, MPI_STATUSES_IGNORE); } else if (rank == 1) { std::thread t1([&]() { MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... }); std::thread t2([&]() { MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... }); t1.join(); t2.join(); } * Two threads from a process A want each to send a message to two threads from a process B using different tags for each pair of threads (e.g. the pair A.1/B.1 uses a different tag from pair A.2/B.2). Code example: // One process with N threads to one process with N thread (different tags) if (rank == 0) { std::thread t1([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); }); std::thread t2([&]() { // Generate data ... MPI_Send(data, 1, MPI_CHAR, 1, 2, MPI_COMM_WORLD); }); t1.join(); t2.join(); } else if (rank == 1) { std::thread t1([&]() { MPI_Recv(data, 1, MPI_CHAR, 0, 1, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... }); std::thread t2([&]() { MPI_Recv(data, 1, MPI_CHAR, 0, 2, MPI_COMM_WORLD, MPI_STATUS_IGNORE); // Process data ... }); t1.join(); t2.join(); } Question 2. Is there a problem when mixing blocking and non-blocking calls on opposite sides of a message? Even in the multithreaded scenarios described previously? (e.g. matching a MPI_Isend with a MPI_Recv, and vice-versa.) Thank you. Regards, Guilherme Valarini

1 0

Questions about MPICH multi-thread support
by Guilherme Valarini 26 Jan '21

26 Jan '21

Dear MPICH community, I am currently developing an event system built upon MPI and I have a few questions about the current state of multi-thread support from MPICH in the *MPI_THREAD_MULTIPLE* mode. *Question 1*. I am aware of the message envelope tuples (source, destination, tag, communicator) that may be used to identify and filter different messages. While using MPICH, can I rely on such information in order to guarantee that the correct messages will reach/be matched with their destinations in a multiprocess multithreaded program? I know this is quite a broad question, but I am more interested in the analysis of the following scenarios. - Two threads in a process A want to send different messages to two different processes, B and C (each with one thread), while using the *same* *communicator* *and* *tag*. Code example: // One process with N threads to N process with one thread (same tag) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 2, 0, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > } > - The same scenario as above, but now each thread uses a *different tag* to communicate to their respective process while only sharing the *same* *communicator*. Code example: // One process with N threads to N process with one thread (different > tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 2, 2, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else { > MPI_Recv(data, 1, MPI_CHAR, 0, rank, MPI_COMM_WORLD, > MPI_STATUS_IGNORE); > } > - Multiple threads from a process A want each to send a message to the same thread of another process B using the *same communicator and* *tag*. Code example: // One process with N threads to one process with one thread (same tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else if (rank == 1) { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > } > - One thread from a process A wants to send a message to one of multiple threads from a process B using the *same communicator and tag*. Code example: // One process with one thread to one process with N threads (same tags) > if (rank == 0) { > MPI_Request requests[2]; > // Generate data ... > MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[0]); > // Generate data ... > MPI_Isend(data, 1, MPI_CHAR, 1, 0, MPI_COMM_WORLD, &requests[1]); > > MPI_Waitall(2, requests, MPI_STATUSES_IGNORE); > } else if (rank == 1) { > std::thread t1([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > std::thread t2([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 0, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > t1.join(); t2.join(); > } > - Two threads from a process A want each to send a message to two threads from a process B using different tags for each pair of threads (e.g. the pair A.1/B.1 uses a different tag from pair A.2/B.2). Code example: // One process with N threads to one process with N thread (different > tags) > if (rank == 0) { > std::thread t1([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 1, MPI_COMM_WORLD); > }); > std::thread t2([&]() { > // Generate data ... > MPI_Send(data, 1, MPI_CHAR, 1, 2, MPI_COMM_WORLD); > }); > t1.join(); t2.join(); > } else if (rank == 1) { > std::thread t1([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 1, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > std::thread t2([&]() { > MPI_Recv(data, 1, MPI_CHAR, 0, 2, MPI_COMM_WORLD, MPI_STATUS_IGNORE); > // Process data ... > }); > t1.join(); t2.join(); > } > *Question 2*. Is there a problem when mixing blocking and non-blocking calls on opposite sides of a message? Even in the multithreaded scenarios described previously? (e.g. matching a *MPI_Isend* with a *MPI_Recv*, and vice-versa.) Thank you. Regards, Guilherme Valarini

1 0

Re: [mpich-discuss] Compile error with MPICH library on IBM machine
by Jeff Hammond 24 Jan '21

24 Jan '21

mpich2-1.4.1 is almost ten years old. You should try something recent if you want MPICH help. Otherwise, you should consult the GCC toolchain folks, although they have seen this before and it appears to be in an unresolved state ( https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=49986) Jeff On Sat, Jan 23, 2021 at 6:39 AM Kihang Youn via discuss <discuss(a)mpich.org> wrote: > > Hello, all. > > I install MPICH on IBM AIX and try to compile pi3f90.f90 in the example, > but I get an error not finding emutls_get_address, muldc3, mulsc3. > There was a similar problem in the previous case, but it's not clear how > it was resolved, so I'm sending you an email. > Old thread: > https://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-August/012920.html > I know that IBM AIX is an OS not supported, but if you have any > suggestions, we ask for a reply. > > Best Regards, > Kihang > > ########## OS version ########## > powerpc-ibm-aix6.1.0.0 > > ########## MPICH version ########## > mpich2-1.4.1 > > ########## Installation Configuration ########## > ./configure CC=gcc F77=xlf_r FC=xlf90_r --disable-shared --enable-static > > ########## GCC version ########## > mpich2-1.4.1 > > ########## Error Message ########## > > ../../bin/mpif90 -o pi3f90 pi3f90.o -lpthread -lm -lc -bnoquiet > > > ld: 0711-317 ERROR: Undefined symbol: .__emutls_get_address(ld): > /lib/crt0.o > (ld): pi3f90.old: 0711-317 ERROR: Undefined symbol: .__muldc3 > (ld): lib /usr/lib/libm.a > ld: 0711-317 ERROR: Undefined symbol: .__mulsc3 > (ld): lib /usr/lib/libc.a > > (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpichf90.a > (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a > (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libopa.a > (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpl.a > ... > LIBRARY: Shared object libxlomp_ser.a[omp_ser.o]: 87 symbols imported. > FILELIST: Number of previously inserted files processed: 14 > > > The following symbols are in error: > Symbol Inpndx TY CL Source-File(Object-File) OR > Import-File{Shared-object} > RLD: Address Section Rld-type Referencing > Symbol > > ---------------------------------------------------------------------------------------------- > .__emutls_get_address [6] ER PR > comm_rank.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[comm_rank.o]) > 00000014 .text R_RBR [34] > <.MPIU_Thread_CS_exit_lockname_recursive_impl_.isra.1.constprop.2> > 00000134 .text R_RBR [36] > <.MPIU_Thread_CS_enter_lockname_recursive_impl_.isra.0.constprop.3> > ... > .__emutls_get_address [2] ER PR > initthread.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[initthread.o]) > 0000001c .text R_RBR [56] > <.MPIU_Thread_CS_exit_lockname_recursive_impl_.isra.1.constprop.2> > 0000014c .text R_RBR [58] > <.MPIU_Thread_CS_enter_lockname_recursive_impl_.isra.0.constprop.3> > .__muldc3 [4] ER PR > opprod.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[opprod.o]) > 00000588 .text R_RBR [14] > .MPIR_PROD > 000009d8 .text R_RBR [14] > .MPIR_PROD > .__mulsc3 [10] ER PR > opprod.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[opprod.o]) > 000010d8 .text R_RBR [14] > .MPIR_PROD > ER: The return code is 8. > make: 1254-004 The error code from the last command is 8. > > > > *Kihang Youn(윤기항)* - Application Analyst | Lenovo DCG Professional > Services > Mobile: +82-10-9374-9396 > E-mail: kyoun(a)lenovo.com > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Compile error with MPICH library on IBM machine
by Kihang Youn 23 Jan '21

23 Jan '21

Hello, all. I install MPICH on IBM AIX and try to compile pi3f90.f90 in the example, but I get an error not finding emutls_get_address, muldc3, mulsc3. There was a similar problem in the previous case, but it's not clear how it was resolved, so I'm sending you an email. Old thread: https://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-August/012920.html I know that IBM AIX is an OS not supported, but if you have any suggestions, we ask for a reply. Best Regards, Kihang ########## OS version ########## powerpc-ibm-aix6.1.0.0 ########## MPICH version ########## mpich2-1.4.1 ########## Installation Configuration ########## ./configure CC=gcc F77=xlf_r FC=xlf90_r --disable-shared --enable-static ########## GCC version ########## mpich2-1.4.1 ########## Error Message ########## ../../bin/mpif90 -o pi3f90 pi3f90.o -lpthread -lm -lc -bnoquiet ld: 0711-317 ERROR: Undefined symbol: .__emutls_get_address(ld): /lib/crt0.o (ld): pi3f90.old: 0711-317 ERROR: Undefined symbol: .__muldc3 (ld): lib /usr/lib/libm.a ld: 0711-317 ERROR: Undefined symbol: .__mulsc3 (ld): lib /usr/lib/libc.a (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpichf90.a (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libopa.a (ld): lib /COE/2020_NIER/mpich2-1.4.1/lib/libmpl.a ... LIBRARY: Shared object libxlomp_ser.a[omp_ser.o]: 87 symbols imported. FILELIST: Number of previously inserted files processed: 14 The following symbols are in error: Symbol Inpndx TY CL Source-File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ---------------------------------------------------------------------------------------------- .__emutls_get_address [6] ER PR comm_rank.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[comm_rank.o]) 00000014 .text R_RBR [34] <.MPIU_Thread_CS_exit_lockname_recursive_impl_.isra.1.constprop.2> 00000134 .text R_RBR [36] <.MPIU_Thread_CS_enter_lockname_recursive_impl_.isra.0.constprop.3> ... .__emutls_get_address [2] ER PR initthread.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[initthread.o]) 0000001c .text R_RBR [56] <.MPIU_Thread_CS_exit_lockname_recursive_impl_.isra.1.constprop.2> 0000014c .text R_RBR [58] <.MPIU_Thread_CS_enter_lockname_recursive_impl_.isra.0.constprop.3> .__muldc3 [4] ER PR opprod.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[opprod.o]) 00000588 .text R_RBR [14] .MPIR_PROD 000009d8 .text R_RBR [14] .MPIR_PROD .__mulsc3 [10] ER PR opprod.c(/COE/2020_NIER/mpich2-1.4.1/lib/libmpich.a[opprod.o]) 000010d8 .text R_RBR [14] .MPIR_PROD ER: The return code is 8. make: 1254-004 The error code from the last command is 8. Kihang Youn(윤기항) - Application Analyst | Lenovo DCG Professional Services Mobile: +82-10-9374-9396 E-mail: kyoun(a)lenovo.com

1 0

Re: [mpich-discuss] Make Error
by Zhou, Hui 22 Jan '21

22 Jan '21

First of all, I notice this message in your log: Warning: File 'test/.deps/strsep.Po' has modification time 16863 s in the future So there is a time issue messing up `make`. Nomally, the particular file `src/util/cvar/mpir_cvars.c` shouldn’t need to be re-made. Secondly, it is weird that the message complains it couldn’t find `src/mpi` directory. Is this something due your particular way of build. For example, I notice you are building out of a temporary folder? -- Hui Zhou From: satyamr via discuss <discuss(a)mpich.org> Date: Friday, January 22, 2021 at 1:49 PM To: Discuss <discuss(a)mpich.org> Cc: satyamr <satyamr(a)iitk.ac.in> Subject: [mpich-discuss] Make Error Installing mpich3.3 from https://www.mpich.org/static/downloads/3.3/ Following the respective installation guide Configure completed without any problem but make is giving error PFA m.txt and c.txt files.

1 0

Make Error
by satyamr 22 Jan '21

22 Jan '21

Installing mpich3.3 from https://www.mpich.org/static/downloads/3.3/ Following the respective installation guide Configure completed without any problem but make is giving error PFA m.txt and c.txt files.

1 0