<div dir="ltr"><div>I don't care that much about C11 _Generic, which is why I have always focused on a C99 solution to the large-count problem, but I disagree with your reasons for abandoning it.</div><div><br></div><div dir="ltr">"silently truncated at run time" is trivially addressed with -Wconversion or -Wshorten-64-to-32.  The example program below is addressed by this.</div><br>$ clang -Wshorten-64-to-32 -c truncation.c <br>truncation.c:10:9: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32]<br>    foo(i);<br>    ~~~ ^<br>1 warning generated.<br><br>$ gcc-9 -Wconversion -c truncation.c <br>truncation.c: In function 'main':<br>truncation.c:10:9: warning: conversion from 'long long int' to 'int' may change value [-Wconversion]<br>   10 |     foo(i);<br>      |         ^<br><br>$ icc -Wconversion -c truncation.c <br>truncation.c(10): warning #1682: implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem)<br>      foo(i);<br>          ^<br><br><div>In any case, incorrect programs are incorrect.  It is a quality-of-implementation issue whether C compilers and MPI libraries detect incorrect usage.  We have never designed MPI around people who can't follow directions and we should not start now.<div><br>Jeff<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 7, 2019 at 6: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">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div></div></div></div></div>