February 2026 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] PMI 2 deprecation in MPICH 5.0.0
by Zhou, Hui 12 Feb '26

12 Feb '26

Felip, Thanks for the question. The original thesis on PMI 2 was too broad, yet not broad enough to meet the current need. For example, a major feature in PMI 2 is multi-thread performance. But in reality, PMI is mainly used during MPI_Init or other non-thread-performance sensitive areas that the complexity added to the design doesn't really justify its usage. In practice, almost all vendors of PMI 2 are simply providing a wrapper that does not take advantage of any PMI 2 features that can't be obtained with the PMI 1 interface. Meanwhile, PMI 2 kills the one feature of PMI 1 -- simplicity. In fact, I believe almost all vendors, regardless what there default interface is, can effortlessly support PMI 1. And because of PMI 1's simplicity, PMI 1 can more easily extend and adapt to new requirement. For example, we have matched the launching scalability using PMI 1 in hydra (MPICH's launcher). And just added one extension allowed us to support MPI sessions dynamic launching. Compared to PMIx, PMIx is overly complex and broad, and it was designed way beyond the scope of MPI. As a result, it is much cumbersome to fork or independently implement PMIx than with PMI 1. Some of the PMIx features, including more advanced KVS scope and PMI events are enticing, but we believe it makes more sense to extend from the simple base of PMI 1 then to inherit the entity of PMIx and control it back. Our current MPICH team is quite lean, but we still think we can keep advancing MPI if we effectively focus. Focusing on PMI 1 is one of such decisions. At this point, PMI 2 is still supported but won't be further developed. Hope this helps. -- Hui ________________________________ From: Felip Moll via discuss <discuss(a)mpich.org> Sent: Thursday, February 12, 2026 11:41 AM To: discuss(a)mpich.org <discuss(a)mpich.org> Cc: Felip Moll <fmoll(a)nvidia.com> Subject: [mpich-discuss] PMI 2 deprecation in MPICH 5.0.0 Hello, MPICH 5. 0. 0 has been released, and the release notes announces that PMI 2 is now deprecated, and recommends switching to PMI 1. It also says PMI 1 upgraded to PMI 1. 2. Looking at some commits I also see that new features will be added ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hello, MPICH 5.0.0 has been released, and the release notes announces that PMI 2 is now deprecated, and recommends switching to PMI 1. It also says PMI 1 upgraded to PMI 1.2. Looking at some commits I also see that new features will be added to PMI 1. I would like to understand the technical reasons behind deprecating PMI 2, as theorically it had a better startup latency, improved KVS, and so on compared to PMI 1 [1] I understand that PMIx should be more appropriate than PMI 2 for large scale apps and this would probably be a reason to reduce efforts on supporting other PMIs, but why keep PMI1 and not PMI2? Where does PMI 2 stand at that point? Thank you!. [1] PMI: A Scalable Parallel Process-Management Interface for Extreme-Scale Systems<https://www.mcs.anl.gov/papers/P1760.pdf > Felip Moll Slurm Sr Engineer NVIDIA<https://urldefense.com/v3/__http:/www.nvidia.com/__;!!LpKI!m1it1uHwfgYmHS7q… > [nvidia.com]<https://urldefense.com/v3/__http:/www.nvidia.com/__;!!LpKI!m1it1uHwfgYmHS7q… >

1 0

PMI 2 deprecation in MPICH 5.0.0
by Felip Moll 12 Feb '26

12 Feb '26

Hello, MPICH 5.0.0 has been released, and the release notes announces that PMI 2 is now deprecated, and recommends switching to PMI 1. It also says PMI 1 upgraded to PMI 1.2. Looking at some commits I also see that new features will be added to PMI 1. I would like to understand the technical reasons behind deprecating PMI 2, as theorically it had a better startup latency, improved KVS, and so on compared to PMI 1 [1] I understand that PMIx should be more appropriate than PMI 2 for large scale apps and this would probably be a reason to reduce efforts on supporting other PMIs, but why keep PMI1 and not PMI2? Where does PMI 2 stand at that point? Thank you!. [1] PMI: A Scalable Parallel Process-Management Interface for Extreme-Scale Systems<https://www.mcs.anl.gov/papers/P1760.pdf > Felip Moll Slurm Sr Engineer NVIDIA<https://urldefense.com/v3/__http:/www.nvidia.com/__;!!LpKI!m1it1uHwfgYmHS7q… > [nvidia.com]<https://urldefense.com/v3/__http:/www.nvidia.com/__;!!LpKI!m1it1uHwfgYmHS7q… >

1 0

REMINDER: Join us Thursday, February 12th for an MPICH BoF as part of CASS Community BoF Days
by Raffenetti, Ken 12 Feb '26

12 Feb '26

Reminder that the MPICH BoF starts in about 30 minutes! There is still time to register and attend. Updated schedule below. Date and Time: Thursday, February 12th, 10:00am – 11:30am Central Time Registration: https://urldefense.us/v3/__https://www.zoomgov.com/meeting/register/EQumnsm… Agenda: * ANL Update – Hui Zhou * Partner Updates * Kim McMahon, Hewlett Packard Enterprise * Nat Shineman, Ohio State University * Simon Pickartz, ParTec AG * Gengbin Zheng, Intel * User Presentations * Nathan Nichols, ANL/ALCF * Junchao Zhang, ANL/PETSc * Q&A Cheers, The MPICH team

1 0

Join us Thursday, February 12th for an MPICH BoF as part of CASS Community BoF Days
by Raffenetti, Ken 09 Feb '26

09 Feb '26

All, The MPICH team will host a Birds-of-a-Feather session this Thursday, February 12th at 10am Central time as part of the CASS Community BoF Days https://urldefense.us/v3/__https://cass.community/news/2026-02-10-cass-bof-… . We hope to see folks there to discuss upcoming MPICH release plans and to hear presentations from MPICH partners and users. Date and Time: Thursday, February 12th, 10:00am – 11:30am Central Time Registration: https://urldefense.us/v3/__https://www.zoomgov.com/meeting/register/EQumnsm… Agenda: * ANL Update – Hui Zhou * Partner Updates * Kim McMahon, Hewlett Packard Enterprise * Nat Shineman, Ohio State University * Simon Pickartz, ParTec AG * Maria Garzaran, Intel * User Presentations * Thomas Applencourt, ANL/ALCF * Junchao Zhang, ANL/PETSc * Q&A Cheers, The MPICH team

1 0

Re: [mpich-discuss] MPICH 5.0.0 released: a warning
by Zhou, Hui 05 Feb '26

05 Feb '26

Jorge, Thanks for reporting BTW. Anyway, if the warnings persist and it causes issues in your workflow or pipeline, please create an issue at https://urldefense.us/v3/__https://github.com/pmodels/mpich/issues__;!!G_uC… . Regardless of my religious belief on programming style, we will try fix the warnings if it is an issue. -- Hui ________________________________ From: jdelia--- via discuss <discuss(a)mpich.org> Sent: Thursday, February 5, 2026 12:09 PM To: MPICH DISCUSS(a)MPICH.ORG <discuss(a)mpich.org> Cc: jdelia(a)intec.unl.edu.ar <jdelia(a)intec.unl.edu.ar> Subject: Re: [mpich-discuss] MPICH 5.0.0 released: a warning Dear Zhou, Houi, Thank you very much for your detailed analysis! It is indeed a bit strange. I obtained that result using the beta version 16. 0. 0 20251216 (experimental) of gcc/gfortran. In any case with the last configuration, that I transcribed ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Dear Zhou, Houi, Thank you very much for your detailed analysis! It is indeed a bit strange. I obtained that result using the beta version 16.0.0 20251216 (experimental) of gcc/gfortran. In any case with the last configuration, that I transcribed in my previous email, these warnings disappeared. Thanks again and regards. Jorge D'Elia. "Zhou, Hui" <zhouh(a)anl.gov<mailto:[email protected]>> escribió: It can be ignored. I am curious how the compiler arrive at that warning. 18446744071562067968 and 18446744073709551615 in hex are 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF, if we cast to unsigned int, they are 2147483648 - 4294967295, and if we cast to signed int, they are -2147483648 - -1. So The compiler looked at the type of upid_len, which is an int, and decided it could have negative values, which will become in the range of 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF and that exceeds maximum object size. So they are complaining an implicit cast from int to size_t in memcpy. And they want us to add an explicit `(unsigned) upid_len` cast, which does nothing in improving the code safety. In fact, it makes the code worse. Before, if we accidentally had negative values in int, which is quite common in errors, the negative value will trigger an immediate error in memcpy. With the cast to (unsigned), the negative values suddenly become good value for memcpy and it will happily corrupt the memory! It is a warning designed to be silenced and force people to write bad code. How stupid is that? -- Hui ________________________________ From: jdelia--- via discuss <discuss(a)mpich.org> Sent: Wednesday, February 4, 2026 5:37 PM To: MPICH DISCUSS(a)MPICH.ORG <discuss(a)mpich.org> Cc: jdelia(a)intec.unl.edu.ar <jdelia(a)intec.unl.edu.ar> Subject: [mpich-discuss] MPICH 5.0.0 released: a warning Hi there, Today I downloaded the [mpich-announce] MPICH 5. 0. 0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: .. /src/mpid/ch4/src/ch4_proc. c: In ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi there, Today I downloaded the [mpich-announce] MPICH 5.0.0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: ../src/mpid/ch4/src/ch4_proc.c: In function ‘MPIDIU_upidhash_add’: ../src/mpid/ch4/src/ch4_proc.c:336:5: warning: ‘memcpy’ specified bound between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 336 | memcpy(t->upid, upid, upid_len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd like to know if it can be ignored, or if it would be better to fix it (and how to do so). Thanks, Regards. Jorge D'Elia.

1 0

Re: [mpich-discuss] MPICH 5.0.0 released: a warning
by Jenke, Joachim 05 Feb '26

05 Feb '26

Hi Hui, I think the proper way to fix the issue is to use size_t for length variables in the first place ;) Regarding your typecasting concern: If I remember correctly, it is implementation-specific behavior, whether widening or unsigned conversion happens first (resulting in 0 or 1 in all additional bits, if the value was negative). Depending on the compiler, your typecast might be the thing that actually happens. If your goal is to always pass an insanely large value for negative values, you should force the widening to happen on signed: (size_t)(long long)upid_len -Joachim Am 05.02.2026 18:06 schrieb "Zhou, Hui via discuss" <discuss(a)mpich.org>: It can be ignored. I am curious how the compiler arrive at that warning. 18446744071562067968 and 18446744073709551615 in hex are 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF, if we cast to unsigned int, they are 2147483648 - 4294967295, and if we cast to signed int, they are -2147483648 - -1. So The compiler looked at the type of upid_len, which is an int, and decided it could have negative values, which will become in the range of 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF and that exceeds maximum object size. So they are complaining an implicit cast from int to size_t in memcpy. And they want us to add an explicit `(unsigned) upid_len` cast, which does nothing in improving the code safety. In fact, it makes the code worse. Before, if we accidentally had negative values in int, which is quite common in errors, the negative value will trigger an immediate error in memcpy. With the cast to (unsigned), the negative values suddenly become good value for memcpy and it will happily corrupt the memory! It is a warning designed to be silenced and force people to write bad code. How stupid is that? -- Hui ________________________________ From: jdelia--- via discuss <discuss(a)mpich.org> Sent: Wednesday, February 4, 2026 5:37 PM To: MPICH DISCUSS(a)MPICH.ORG <discuss(a)mpich.org> Cc: jdelia(a)intec.unl.edu.ar <jdelia(a)intec.unl.edu.ar> Subject: [mpich-discuss] MPICH 5.0.0 released: a warning Hi there, Today I downloaded the [mpich-announce] MPICH 5. 0. 0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: .. /src/mpid/ch4/src/ch4_proc. c: In ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi there, Today I downloaded the [mpich-announce] MPICH 5.0.0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: ../src/mpid/ch4/src/ch4_proc.c: In function ‘MPIDIU_upidhash_add’: ../src/mpid/ch4/src/ch4_proc.c:336:5: warning: ‘memcpy’ specified bound between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 336 | memcpy(t->upid, upid, upid_len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd like to know if it can be ignored, or if it would be better to fix it (and how to do so). Thanks, Regards. Jorge D'Elia.

1 0

Re: [mpich-discuss] MPICH 5.0.0 released: a warning
by jdelia＠intec.unl.edu.ar 05 Feb '26

05 Feb '26

Dear Zhou, Houi, Thank you very much for your detailed analysis! It is indeed a bit strange. I obtained that result using the beta version 16.0.0 20251216 (experimental) of gcc/gfortran. In any case with the last configuration, that I transcribed in my previous email, these warnings disappeared. Thanks again and regards. Jorge D'Elia. "Zhou, Hui" <zhouh(a)anl.gov> escribió: > It can be ignored. > > I am curious how the compiler arrive at that warning. > 18446744071562067968 and 18446744073709551615 in hex are > 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF, if we cast to unsigned > int, they are 2147483648 - 4294967295, and > if we cast to signed int, they are -2147483648 - -1. So The compiler > looked at the type of upid_len, which is an int, and > decided it could have negative values, which will become in the > range of 0xFFFFFFFF80000000 and > 0xFFFFFFFFFFFFFFFF and that exceeds maximum object size. > > So they are complaining an implicit cast from int to size_t in > memcpy. And they want us to add an explicit > `(unsigned) upid_len` cast, which does nothing in improving the code > safety. In fact, it makes the code worse. Before, if we > accidentally had negative values in int, which is quite common in > errors, the negative value will trigger an immediate error > in memcpy. With the cast to (unsigned), the negative values > suddenly become good value for memcpy and it will happily > corrupt the memory! It is a warning designed to be silenced and > force people to write bad code. > > How stupid is that? > > -- > Hui > > ------------------------- > FROM: jdelia--- via discuss <discuss(a)mpich.org> > SENT: Wednesday, February 4, 2026 5:37 PM > TO: MPICH DISCUSS(a)MPICH.ORG <discuss(a)mpich.org> > CC: jdelia(a)intec.unl.edu.ar <jdelia(a)intec.unl.edu.ar> > SUBJECT: [mpich-discuss] MPICH 5.0.0 released: a warning > > Hi there, Today I downloaded the [mpich-announce] MPICH > 5. 0. 0 released on a x86_64-pc-linux-gnu Linux machine with Fedora > 43. Although the building is fine, the following warning appears > during compilation: .. /src/mpid/ch4/src/ch4_proc. c: In > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside your organization. > > > > ZjQcmQRYFpfptBannerEnd > > Hi there, > > Today I downloaded the [mpich-announce] MPICH 5.0.0 released > on a x86_64-pc-linux-gnu Linux machine with Fedora 43. > > Although the building is fine, the following warning appears during > compilation: > > ../src/mpid/ch4/src/ch4_proc.c: In function ‘MPIDIU_upidhash_add’: > ../src/mpid/ch4/src/ch4_proc.c:336:5: warning: ‘memcpy’ > specified bound between 18446744071562067968 and > 18446744073709551615 exceeds maximum object size 9223372036854775807 > [-Wstringop-overflow=] > 336 | memcpy(t->upid, upid, upid_len); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I'd like to know if it can be ignored, or if it would be better to > fix it (and > how to do so). Thanks, > > Regards. > > Jorge D'Elia. >

1 0

Re: [mpich-discuss] MPICH 5.0.0 released: a warning
by Zhou, Hui 05 Feb '26

05 Feb '26

It can be ignored. I am curious how the compiler arrive at that warning. 18446744071562067968 and 18446744073709551615 in hex are 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF, if we cast to unsigned int, they are 2147483648 - 4294967295, and if we cast to signed int, they are -2147483648 - -1. So The compiler looked at the type of upid_len, which is an int, and decided it could have negative values, which will become in the range of 0xFFFFFFFF80000000 and 0xFFFFFFFFFFFFFFFF and that exceeds maximum object size. So they are complaining an implicit cast from int to size_t in memcpy. And they want us to add an explicit `(unsigned) upid_len` cast, which does nothing in improving the code safety. In fact, it makes the code worse. Before, if we accidentally had negative values in int, which is quite common in errors, the negative value will trigger an immediate error in memcpy. With the cast to (unsigned), the negative values suddenly become good value for memcpy and it will happily corrupt the memory! It is a warning designed to be silenced and force people to write bad code. How stupid is that? -- Hui ________________________________ From: jdelia--- via discuss <discuss(a)mpich.org> Sent: Wednesday, February 4, 2026 5:37 PM To: MPICH DISCUSS(a)MPICH.ORG <discuss(a)mpich.org> Cc: jdelia(a)intec.unl.edu.ar <jdelia(a)intec.unl.edu.ar> Subject: [mpich-discuss] MPICH 5.0.0 released: a warning Hi there, Today I downloaded the [mpich-announce] MPICH 5. 0. 0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: .. /src/mpid/ch4/src/ch4_proc. c: In ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi there, Today I downloaded the [mpich-announce] MPICH 5.0.0 released on a x86_64-pc-linux-gnu Linux machine with Fedora 43. Although the building is fine, the following warning appears during compilation: ../src/mpid/ch4/src/ch4_proc.c: In function ‘MPIDIU_upidhash_add’: ../src/mpid/ch4/src/ch4_proc.c:336:5: warning: ‘memcpy’ specified bound between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 336 | memcpy(t->upid, upid, upid_len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I'd like to know if it can be ignored, or if it would be better to fix it (and how to do so). Thanks, Regards. Jorge D'Elia.

1 0

Re: [mpich-discuss] MPICH 5.0.0 released: a warning (some more warnings)
by jdelia＠intec.unl.edu.ar 05 Feb '26

05 Feb '26

Hi everyone, Please disregard my previous question. Today I started again with new configuration options: ../configure --with-device=ch4:ucx --enable-shared --enable-fortran --enable-fast=avx --enable-mpit-pvars=all --prefix=${PREFIX} 2>&1 | tee configure.eco and then the warning messages during the make step have now been reduced to two: ../../../modules/json-c/arraylist.c: In function ‘array_list_new’: ../../../modules/json-c/arraylist.c:49:43: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] 49 | if(!(arr->array = (void**)calloc(sizeof(void*), arr->size))) { | ^~~~ ../../../modules/json-c/arraylist.c:49:43: note: earlier argument should specify number of elements, later size of each element ../../../modules/json-c/json_object.c: In function ‘json_object_new’: ../../../modules/json-c/json_object.c:231:50: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] Regards, Jorge D'Elia. --

1 0

MPICH 5.0.0 released: a warning (some more warnings)
by jdelia＠intec.unl.edu.ar 04 Feb '26

04 Feb '26

Hi again, Below some other warnings. Regards. Jorge 'D'Elia. -- In file included from /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl_atomic_c11.h:20, from /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl_atomic.h:101, from /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl.h:16, from ../src/include/mpiimpl.h:53, from ../src/mpi/attr/attrutil.c:6: In function ‘MPL_atomic_release_store_int’, inlined from ‘MPID_Attr_alloc’ at ../src/mpi/attr/attrutil.c:48:5, inlined from ‘MPIR_Attr_dup_list’ at ../src/mpi/attr/attrutil.c:167:17: /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl_atomic_c11.h:59:5: warning: ‘__atomic_store_4’ writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] 59 | atomic_store_explicit(&ptr->v, (CAST_TYPE)val, memory_order_release); \ | ^~~~~~~~~~~~~~~~~~~~~ /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl_atomic_c11.h:93:9: note: in expansion of macro ‘MPLI_ATOMIC_DECL_FUNC_COMMON’ 93 | MPLI_ATOMIC_DECL_FUNC_COMMON(TYPE, NAME, ATOMIC_TYPE, CAST_TYPE) \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/bigpack/mpich-paq/mpich-5.0.0/src/mpl/include/mpl_atomic_c11.h:99:1: note: in expansion of macro ‘MPLI_ATOMIC_DECL_FUNC_VAL’ 99 | MPLI_ATOMIC_DECL_FUNC_VAL(int, int, atomic_int, int) | ^~~~~~~~~~~~~~~~~~~~~~~~~ In function ‘MPIR_Attr_dup_list’: cc1: note: destination object is likely at address zero. ... CC src/mpi/coll/barrier/lib_libmpi_la-barrier_inter_bcast.lo ../src/mpi/coll/barrier/barrier_intra_k_dissemination.c: In function ‘MPIR_Barrier_intra_k_dissemination’: ../src/mpi/coll/barrier/barrier_intra_k_dissemination.c:120:9: warning: ‘MPIC_Waitall’ accessing 8 bytes in a region of size 0 [-Wstringop-overflow=] 120 | MPIC_Waitall(k - 1, recv_reqs + ((k - 1) * ((nphases - 1) & 1)), MPI_STATUSES_IGNORE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/mpi/coll/barrier/barrier_intra_k_dissemination.c:120:9: note: referencing argument 2 of type ‘MPIR_Request *[0]’ In file included from ../src/include/mpiimpl.h:208, from ../src/mpi/coll/barrier/barrier_intra_k_dissemination.c:6: ../src/include/mpir_coll.h:48:5: note: in a call to function ‘MPIC_Waitall’ 48 | int MPIC_Waitall(int numreq, MPIR_Request * requests[], MPI_Status * statuses); | ^~~~~~~~~~~~ CC src/mpi/coll/bcast/lib_libmpi_la-bcast_utils.lo CC src/mpid/ch4/src/lib_libmpi_la-ch4_proc.lo ../src/mpid/ch4/src/ch4_proc.c: In function ‘MPIDIU_upidhash_add’: ../src/mpid/ch4/src/ch4_proc.c:336:5: warning: ‘memcpy’ specified bound between 18446744071562067968 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 336 | memcpy(t->upid, upid, upid_len); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC src/mpid/ch4/src/lib_libmpi_la-ch4_stream_enqueue.lo end.

1 0