[Mpi-forum] Giving up on C11 _Generic

Jeff Hammond jeff.science at gmail.com
Wed Aug 7 15:14:23 CDT 2019

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.

"silently truncated at run time" is trivially addressed with -Wconversion
or -Wshorten-64-to-32.  The example program below is addressed by this.

$ clang -Wshorten-64-to-32 -c truncation.c
truncation.c:10:9: warning: implicit conversion loses integer precision:
'long long' to 'int' [-Wshorten-64-to-32]
    ~~~ ^
1 warning generated.

$ gcc-9 -Wconversion -c truncation.c
truncation.c: In function 'main':
truncation.c:10:9: warning: conversion from 'long long int' to 'int' may
change value [-Wconversion]
   10 |     foo(i);
      |         ^

$ icc -Wconversion -c truncation.c
truncation.c(10): warning #1682: implicit conversion of a 64-bit integral
type to a smaller integral type (potential portability problem)

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.


On Wed, Aug 7, 2019 at 6:59 AM Jeff Squyres (jsquyres) via mpi-forum <
mpi-forum at lists.mpi-forum.org> wrote:

> =============
> 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.
> ===========
> Joseph Schuchart raised a very important point in a recent mailing thread:
> the following C/C++ code does not raise a compiler warning:
> -----
> #include <stdio.h>
> static void foo(int j) {
>     printf("foo(j) = %d\n", j);
> }
> int main(int argc, char *argv[]) {
>     /* 8589934592LL == 2^33 */
>     long long i = 8589934592LL + 11;
>     foo(i);
>     return 0;
> }
> -----
> 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.
> This is because casting from a larger int type to a smaller int type is
> perfectly valid C/C++.
> Because of this, there is a possibility that we could be silently
> introducing errors into user applications.  Consider:
> 1. An application upgrades its "count" parameters to type MPI_Count for
> all calls to MPI_Send.
>    --> Recall that "MPI_Count" already exists in MPI-3.1, and is likely of
> type (long long) on commodity x86-64 platforms
> 2. The application then uses values in that "count" parameter that are
> greater than 2^32.
> If the user's MPI implementation and compiler both support C11 _Generic,
> everything is great.
> But if either the MPI implementation or the compiler do not support C11
> _Generic, ***the "count" value will be silently truncated at run time***.
> This seems like a very bad idea, from a design standpoint.
> 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.
> Note that Fortran does not have similar problems:
> 1. Fortran compilers have supported polymorphism for 20+ years
> 2. Fortran does not automatically cast between INTEGER values of different
> sizes
> After much debate, the BigCount WG has decided that C11 _Generic just
> isn't worth it.  That's no reason to penalize Fortran, though.
> --
> Jeff Squyres
> jsquyres at cisco.com
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Jeff Hammond
jeff.science at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20190807/802b10e6/attachment-0001.html>

More information about the mpi-forum mailing list