- discuss - mailman3.cels.anl.gov

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

MPICH 5.0.0 released: a warning
by jdelia＠intec.unl.edu.ar 04 Feb '26

04 Feb '26

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

MPI Debugging Community Website and Short Survey
by Junchao Zhang 26 Jan '26

26 Jan '26

Dear MPICH friends,Apologies for the interruption. With support from the BSSw <https://urldefense.us/v3/__https://bssw.io/__;!!G_uCfscf7eWS!a9jsd3H1cObVV7… > Fellowship Program, I have set up a community website, https://urldefense.us/v3/__https://mpi-debug.org__;!!G_uCfscf7eWS!a9jsd3H1c… , for the community to share MPI debugging tips, tools, and experiences. You are very welcome to start discussions or share ideas at https://urldefense.us/v3/__https://github.com/mpi-debug/mpi-debug.github.io… . In addition, I would greatly appreciate it if you could take a *very brief* survey at https://urldefense.us/v3/__https://forms.gle/cUbXUfu2Z2dK5d9V7__;!!G_uCfscf… . The goal is to better understand the current landscape of MPI debugging practices. Thank you very much for your time and support. Best regards, -- Junchao Zhang

1 0

Join us for the MPICH BoF Wednesday evening at SC25
by Raffenetti, Ken 13 Nov '25

13 Nov '25

All, The MPICH team will host a Birds-of-a-Feather session Wednesday evening as part of the SC25 proceedings. We hope you will join us to discuss the latest MPICH developments and hear from the community. Date and Time: Wednesday, November 19th, 5:15pm - 6:45pm CST Location: 125 Agenda: * Welcome and ANL Update * Welcome – Ken Raffenetti * ANL Update – Yanfei Guo & Hui Zhou * Partner Presentations * Maria Garzaran, Intel * Nathaniel Shineman, MVAPICH * Simon Pickartz, ParTec AG * Naveen Ravi, HPE * Jeff Hammond, NVIDIA * Mike Wilkins, Cornelis Networks * User Presentations * Thomas Applencourt, ANL/ALCF * Q&A https://urldefense.us/v3/__https://sc25.conference-program.com/presentation… Cheers, The MPICH team

1 0

Re: [mpich-discuss] Error in MPI_IRECV
by phani sri 19 Oct '25

19 Oct '25

Thank you very much, adding -std=legacy to gfortrans compiler flags has solved the problem. On Mon, 20 Oct 2025 at 02:32, fistrosan via discuss <discuss(a)mpich.org> wrote: > If Gregor's answer does not solve it try adding -std=legacy to gfortrans > compiler flags. Sent from Proton Mail for Android. -------- Original > Message -------- On Friday, 10/17/25 at 14: 26 Gregor Corbin via discuss > <discuss@ mpich. org> wrote: > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside your organization. > > ZjQcmQRYFpfptBannerEnd > If Gregor's answer does not solve it try adding -std=legacy to gfortrans > compiler flags. > > > > Sent from Proton Mail > <https://urldefense.us/v3/__https://proton.me/mail/home__;!!G_uCfscf7eWS!dJK…> > for Android. > > > -------- Original Message -------- > On Friday, 10/17/25 at 14:26 Gregor Corbin via discuss <discuss(a)mpich.org> > wrote: > > Hi, > > let me guess: this code uses `include mpif.h` and is compiled with > gfortran. If so, try to add `-fallow-argument-mismatch' to your compiler > flags. > > Explanation: With the include file, there are no explicit interfaces and > the compiler generates an implicit interface from the call to `MPI_IRECV`. > Having two calls with different argument types is an error since some gcc > version (10 IIRC). > > Cheers, > > Gregor Corbin > > > On 17.10.25 13:30, phani sri via discuss wrote: > > Hi all, I am trying to run FLASH4. 8, where I am getting the following > error. Can someone please, suggest to me why this error is coming. Thank > you in advance. 497 | Call MPI_IRECV(parentt(1,i),2,MPI_INTEGER, > & > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside your organization. > > ZjQcmQRYFpfptBannerEnd > Hi all, I am trying to run FLASH4.8, where I am getting the following > error. Can someone please, suggest to me why this error is coming. > Thank you in advance. > 497 | Call MPI_IRECV(parentt(1,i),2,MPI_INTEGER, > & > | 2 > ...... > 633 | Call MPI_IRECV(buffert(1,i),buf_size, > & > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (REAL(8)/INTEGER(4)). > amr_migrate_tree_data.F90:642:23: > > 497 | Call MPI_IRECV(parentt(1,i),2,MPI_INTEGER, > & > | 2 > ...... > 642 | Call MPI_IRECV(newchildt(i),1,MPI_LOGICAL, > & > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (LOGICAL(4)/INTEGER(4)). > amr_migrate_tree_data.F90:717:23: > > 513 | Call MPI_SSEND (new_loc(1,i),2,MPI_INTEGER, > & > | 2 > ...... > 717 | Call MPI_SSEND(buffer(1),buf_size,amr_mpi_real, > & > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (REAL(8)/INTEGER(4)). > amr_migrate_tree_data.F90:725:23: > > 513 | Call MPI_SSEND (new_loc(1,i),2,MPI_INTEGER, > & > | 2 > ...... > 725 | Call MPI_SSEND(newchild(i),1,MPI_LOGICAL, > & > | 1 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (LOGICAL(4)/INTEGER(4)). > amr_migrate_tree_data.F90:260:25: > > 260 | Call MPI_IRECV(buffert(1,i),buf_size, > & > | 1 > ...... > 497 | Call MPI_IRECV(parentt(1,i),2,MPI_INTEGER, > & > | 2 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (REAL(8)/INTEGER(4)). > amr_migrate_tree_data.F90:269:25: > > 269 | Call MPI_IRECV(newchildt(i),1,MPI_LOGICAL, > & > | 1 > ...... > 497 | Call MPI_IRECV(parentt(1,i),2,MPI_INTEGER, > & > | 2 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (LOGICAL(4)/INTEGER(4)). > amr_migrate_tree_data.F90:330:25: > > 330 | Call MPI_SSEND(buffer(1),buf_size,amr_mpi_real, > & > | 1 > ...... > 513 | Call MPI_SSEND (new_loc(1,i),2,MPI_INTEGER, > & > | 2 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (REAL(8)/INTEGER(4)). > amr_migrate_tree_data.F90:338:25: > > 338 | Call MPI_SSEND(newchild(i),1,MPI_LOGICAL, > & > | 1 > ...... > 513 | Call MPI_SSEND (new_loc(1,i),2,MPI_INTEGER, > & > | 2 > Error: Type mismatch between actual argument at (1) and actual argument at > (2) (LOGICAL(4)/INTEGER(4)). > amr_restrict_ec_genorder.F90:310:37: > > > > -- > *Dr. D. P. S. L. Kameswari* > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe:https://urldefense.us/v3/__https://lists.mpich.org/mailman/list… <https://urldefense.us/v3/__https://lists.mpich.org/mailman/listinfo/discuss…> > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://urldefense.us/v3/__https://lists.mpich.org/mailman/listinfo/discuss… > -- *Dr. D. P. S. L. Kameswari*

1 0