<div dir="ltr"><div dir="ltr">Jeff, I don't think we all agree 100% to abandon C11 _Generic, and let me feedback to you what you write below for further argumentation;</div><div dir="ltr">I am a bit surprised this is in front of the whole forum just one day after WG discussions, when more WG discussions are still in order weeks before the finalization of our proposals for Zurich.<br> <div>This statement alone </div><div><br></div><div>"But if either the MPI implementation or the compiler do not support C11 _Generic, ***the "count" value will be silently truncated at run time***."<br></div><div><br></div><div>is not a sufficient reason for abandoning C11 _Generic.</div><div>1) MPI Implementations have to either support MPI-4 or not; it would not be optional. Therefore the MPI implementation is incomplete.</div><div>Therefore this is not a reason to abandon C11.</div><div><br></div><div>2) If the compiler environment doesn't support C11 _Generic, then the build process for MPI would have to warn the user or that kind of platform would be impossible to use with MPI-4. Seems harsh for non-compliant compilers.</div><div><br></div><div>These are not sufficient conditions alone for abandoning C11 _Generic. </div><div><br></div><div>Conclusion: You can't use non-compliant MPI-4 with C11 compilers that are non-compliant with C11, except maybe with a special flag???</div><div>Is there more that I am missing?</div><div><br></div><div>Do you have other reasons that I've missed or you don't cite below besides a) non-compliant MPI implementation, b) non-compliant C11 compiler for abandoning this feature? These are both reasons that an MPI program would not do what it should. But you also write</div><div><br></div><div>"If the user's MPI implementation and compiler both support C11 _Generic, everything is great."</div><div><br></div><div>I realize that I was not on the full meetings recently, but this major change of heart, although shared by others on the phone yesterday, is not unanimous (and not everyone spoke up). Maybe I am missing deeper arguments, because you yourself say that correct implementation with a correct compiler produces valid outcomes.</div><div><br></div><div>Notice how this kind of problem with Long vs. int exists in the C interface currently; whenever you have a long long int argument, and you pass this to a current C API that takes an int (for a count), this truncation occurs. Do you agree?</div><div><br></div><div>Help me to understand better why we should overthrow this approach.</div><div><br></div><div>Regards,</div><div>Tony</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 9:59 AM Jeff Squyres (jsquyres) via mpi-forum <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">SHORT VERSION<br>
=============<br>
<br>
Due to the possibility of silently introducing errors into user applications, the BigCount WG no longer thinks that C11 _Generic is a good idea. We are therefore dropping that from our proposal. The new proposal will therefore essentially just be the addition of a bunch of MPI_Count-enabled "_x" functions in C, combined with the addition of a bunch of polymorphic MPI_Count-enabled interfaces in Fortran.<br>
<br>
MORE DETAIL<br>
===========<br>
<br>
Joseph Schuchart raised a very important point in a recent mailing thread: the following C/C++ code does not raise a compiler warning:<br>
<br>
-----<br>
#include <stdio.h><br>
<br>
static void foo(int j) {<br>
printf("foo(j) = %d\n", j);<br>
}<br>
<br>
int main(int argc, char *argv[]) {<br>
/* 8589934592LL == 2^33 */<br>
long long i = 8589934592LL + 11;<br>
foo(i);<br>
return 0;<br>
}<br>
-----<br>
<br>
If you compile and run this program on a commodity x86-64 platform, a) you won't get a warning from the compiler, and b) you'll see "11" printed out. I tried with gcc 9 and clang 8 -- both with the C and C++ compilers. I even tried with "-Wall -pedantic". No warnings.<br>
<br>
This is because casting from a larger int type to a smaller int type is perfectly valid C/C++.<br>
<br>
Because of this, there is a possibility that we could be silently introducing errors into user applications. Consider:<br>
<br>
1. An application upgrades its "count" parameters to type MPI_Count for all calls to MPI_Send.<br>
--> Recall that "MPI_Count" already exists in MPI-3.1, and is likely of type (long long) on commodity x86-64 platforms<br>
2. The application then uses values in that "count" parameter that are greater than 2^32.<br>
<br>
If the user's MPI implementation and compiler both support C11 _Generic, everything is great.<br>
<br>
But if either the MPI implementation or the compiler do not support C11 _Generic, ***the "count" value will be silently truncated at run time***.<br>
<br>
This seems like a very bad idea, from a design standpoint.<br>
<br>
We have therefore come full circle: we are back to adding a bunch of "_x" functions for C, and there will be no polymorphism (in C). Sorry, folks.<br>
<br>
Note that Fortran does not have similar problems:<br>
<br>
1. Fortran compilers have supported polymorphism for 20+ years<br>
2. Fortran does not automatically cast between INTEGER values of different sizes<br>
<br>
After much debate, the BigCount WG has decided that C11 _Generic just isn't worth it. That's no reason to penalize Fortran, though.<br>
<br>
-- <br>
Jeff Squyres<br>
<a href="mailto:jsquyres@cisco.com" target="_blank">jsquyres@cisco.com</a><br>
<br>
_______________________________________________<br>
mpi-forum mailing list<br>
<a href="mailto:mpi-forum@lists.mpi-forum.org" target="_blank">mpi-forum@lists.mpi-forum.org</a><br>
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpi-forum" rel="noreferrer" target="_blank">https://lists.mpi-forum.org/mailman/listinfo/mpi-forum</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Tony Skjellum, PhD<br>RunTime Computing Solutions, LLC<br><a href="mailto:tony@runtimecomputing.com" target="_blank">tony@runtimecomputing.com</a><br>direct: +1-423-713-9337<br>cell: +1-205-807-4968<br></div></div></div></div></div></div>