[mpich-discuss] MPICH 5.0.0 released: a warning

[Zhou, Hui]

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_uCfscf7eWS!dihfotRyPnACJxGTEUpiKZuSltFk3i0MlWDTmWXmV9_u2-MNj81PERegD4KFu2zw5Wv9uxr50m34$ . 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 at mpich.org>
Sent: Thursday, February 5, 2026 12:09 PM
To: MPICH DISCUSS at MPICH.ORG <discuss at mpich.org>
Cc: jdelia at intec.unl.edu.ar <jdelia at 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 at anl.gov<mailto:zhouh at 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 at mpich.org>
Sent: Wednesday, February 4, 2026 5:37 PM
To: MPICH DISCUSS at MPICH.ORG <discuss at mpich.org>
Cc: jdelia at intec.unl.edu.ar <jdelia at 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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20260205/185345e5/attachment.html>